a-module

Invalid verdict received from threat inspection engine

This counter increments when the threat defense data path receives an invalid or out-of-range verdict code from the Snort inspection engine. The data path validates all verdict messages from Snort (pass, block, fast-forward, blacklist, etc.) and drops packets when the verdict type exceeds the expected range or when the verdict reason code falls outside the defined enumeration boundaries. This can occur due to communication errors between the data path and Snort process, version mismatches, or internal software defects. The counter also increments when Snort returns an unsupported verdict type for non-IP packets (only pass, block, and drop-silent verdicts are valid for Layer 2 traffic). This drop reason was historically used as a catch-all for various Snort-related drop conditions before more granular drop reasons were introduced in later releases.

Recommendation:

Occasional increments may occur during Snort process restarts or software upgrades and are typically benign. Sustained or frequent increments indicate a problem with the Snort inspection engine or the communication channel between the data path and Snort. Check the health of the Snort process with 'show snort status' and review system logs for Snort errors or crashes. If the counter increments persistently, collect a troubleshooting bundle and contact Cisco TAC. Verify that the system is running a current software version, as older releases used this counter more broadly for conditions that now have specific drop reasons. If the issue correlates with specific traffic patterns (especially non-IP protocols), enable packet capture with 'capture type asp-drop a-module' to identify the affected flows.

Syslogs:

None.

----------------------------------------------------------------

acl-drop

Packet denied by access control policy

This counter increments when a packet or connection attempt is denied by an access control rule. Denials can result from multiple policy enforcement points: (1) explicit deny rules in access control lists applied to interfaces, (2) implicit deny rules when no permit rule matches, (3) per-user or per-group access lists downloaded from AAA servers during authentication or authorization, (4) VPN filter lists applied to IPsec or L2TP sessions, (5) through-traffic arriving on a management-only interface, which is restricted to control-plane protocols only, or (6) unencrypted traffic arriving on an interface configured to require IPsec encryption. The counter tracks both ingress and egress ACL denials. When a deny rule is matched, the device typically generates a syslog message identifying the specific rule, source, destination, and interface involved.

Recommendation:

Review the associated syslog messages (106023, 106100, 106004) to identify which access control rule denied the traffic and on which interface. Check whether the denial is intentional security policy or a misconfiguration. For interface ACLs, use 'show access-list' to verify rule order and hit counts. If the traffic should be permitted, add an explicit permit rule before the denying rule or implicit deny. For AAA-related denials, verify the downloadable ACLs or filter attributes returned by the RADIUS or TACACS+ server match your intent. For management-only interface denials, ensure data-plane traffic is directed to data interfaces, not the management interface. For IPsec interface denials, confirm that traffic arriving on crypto-enabled interfaces is properly encrypted or adjust the interface security policy. Persistent unexpected denials may indicate a routing misconfiguration, asymmetric traffic flow, or an overly restrictive security policy.

Syslogs:

106023, 106100, 106004

----------------------------------------------------------------

app-recv-queue-not-ready

Inspection engine communication queue not ready

Packets were dropped because the threat detection engine was in a transitional state and could not accept traffic for inspection. This occurs during brief windows when the inspection engine is starting up, shutting down, restarting, or transitioning between operational states. Common triggers include system boot, policy deployment that requires an inspection engine restart, configuration changes that affect inspection services, or high-availability failover events. On hardware-accelerated platforms, the datapath detects that the inspection engine peer is not yet ready to process packets and drops them rather than queuing indefinitely. The counter typically increments in short bursts during these state transitions and should return to zero once the inspection engine reaches a stable operational state.

Recommendation:

This counter incrementing during system boot, policy deployment, or configuration changes is expected behavior and does not indicate a problem. The drops are temporary and traffic resumes automatically once the inspection engine completes its state transition. If the counter continues incrementing during steady-state operation (no deployments, reboots, or configuration changes), verify the inspection engine status with 'show asp inspect-dp snort status' and check for repeated restart cycles. On inline-pair interfaces with fail-open configured, be aware that packets may experience delays of several seconds during inspection engine restarts; for latency-sensitive traffic that does not require inspection, consider using prefilter policies with fastpath actions to bypass inspection. If drops occur frequently outside of known maintenance windows or the inspection engine fails to stabilize, collect troubleshooting data and contact Cisco TAC.

Syslogs:

None.

----------------------------------------------------------------

appid

Traffic blocked by application identification policy

This counter increments when traffic is dropped because the Snort application identification (AppID) engine determined the traffic matches an application that is blocked by an access control policy rule. AppID identifies applications in network traffic regardless of port or protocol, and this drop occurs when a policy rule with an application condition evaluates to a block or deny action. This is specific to FTD (Firepower Threat Defense) platforms where access control policies are managed through FMC (Firepower Management Center). The drop happens after Snort inspects the traffic, identifies the application, and determines that the configured policy requires the traffic to be blocked.

Recommendation:

Use packet tracer with Snort information enabled to see which application was identified and which access control rule triggered the block. Review your access control policy in FMC to verify that the application blocking behavior is intentional. Check the application conditions in your access control rules—if the identified application should be allowed, modify the rule or add a more specific allow rule with higher priority. If the application identification appears incorrect, verify that AppID detectors are up to date and consider reviewing Snort performance counters with 'show snort counters appid' to ensure the AppID subsystem is functioning properly. This drop is typically by design when application-based access control is configured; contact TAC only if legitimate applications are being misidentified or if the drop does not correlate with any configured policy rule.

Syslogs:

None.

----------------------------------------------------------------

async-lock-queue-limit

Packet dispatch queue limit exceeded

The firewall uses internal work queues to distribute packet processing across multiple CPU cores. Each queue has a limit of 1000 packets. This counter increments when incoming packets cannot be queued because the target queue is full. Packets are assigned to queues based on a hash of their flow characteristics (source/destination IP, ports, protocol), so all packets belonging to the same connection or related connections are processed by the same CPU core. This drop occurs when traffic arrives faster than a single core can process it, typically during high-rate traffic bursts, asymmetric traffic patterns in clustering or high-availability configurations, or when many connections hash to the same queue. The queue limit protects the system from memory exhaustion but results in packet loss when sustained load exceeds per-core processing capacity.

Recommendation:

This drop indicates a CPU core is overloaded processing packets for specific flows. Check overall CPU utilization and per-core statistics to identify if one or more cores are saturated while others are idle, which suggests uneven traffic distribution. Review traffic patterns: large numbers of connections from the same source IP or to the same destination may concentrate load on a single core. In cluster or high-availability deployments, verify that traffic is distributed evenly across cluster members and that failover or cluster control plane traffic is not overwhelming the standby unit. If drops persist under normal load, consider redistributing traffic sources, enabling traffic shaping to smooth bursts, or upgrading to a platform with higher per-core performance. Occasional drops during brief traffic spikes are typically benign and will trigger TCP retransmissions, but sustained drops indicate insufficient processing capacity for the traffic pattern.

Syslogs:

None.

----------------------------------------------------------------

back-orifice

Traffic blocked by Back Orifice detection

This counter increments when the intrusion detection engine identifies UDP traffic matching the signature of Back Orifice, a legacy remote administration trojan that targets Windows systems. The detection occurs when a Network Analysis Policy with the Back Orifice preprocessor enabled is applied to the traffic. The preprocessor analyzes UDP packets for specific patterns associated with the Back Orifice malware family. In rare cases, legitimate encrypted traffic such as DTLS VPN connections may trigger false positives, particularly on older software versions. The drop occurs only when both the preprocessor is enabled in the Network Analysis Policy and the traffic matches the detection signature.

Recommendation:

Review intrusion events in the management center to determine whether the detected traffic is legitimate or malicious. If you are experiencing false positives on known-good traffic (such as VPN connections), consider disabling the Back Orifice preprocessor in the Network Analysis Policy settings, as this threat is largely obsolete in modern networks. You can also disable specific Back Orifice detection rules (such as GID 1 SID 3155, 12148, 12149, or GID 116 SID 112) if you need more granular control. Use packet capture or packet tracer with intrusion event correlation to confirm whether the traffic is truly malicious before taking action. If legitimate business traffic is being blocked and you cannot disable the preprocessor, contact Cisco TAC for assistance.

Syslogs:

None. Intrusion events may be generated in the management center event viewer.

----------------------------------------------------------------

backplane-channel-null

Backplane channel to security services module unavailable

The system attempted to send or receive traffic over the backplane communication channel to a Security Services Module (SSM), but the channel was not available. This occurs on ASA 5500 series platforms with SSM slots when module-related operations execute while the backplane channel is closed or not initialized. Common scenarios include: clustering enable/disable operations when no physical SSM card is installed, SSM card removal or failure, or during system initialization before the module channel is fully established. The counter typically increments in small bursts (proportional to the number of interfaces) during configuration changes rather than continuously.

Recommendation:

This counter is typically benign and does not indicate a problem if it increments occasionally during configuration changes, especially clustering operations. If the counter increments continuously or in large volumes during normal traffic forwarding, verify: (1) the SSM card (CX, IPS, or SFR module) is properly seated and operational using 'show module' commands, (2) check for syslog messages indicating SSM health check failures or control channel communication failures (323001, 323006), (3) if no SSM card is installed but SSM-related policies are configured, remove the unused service policies. Contact Cisco TAC if drops occur continuously during stable operation with a properly functioning SSM card.

Syslogs:

323001 (Module control channel communication failure), 323006 (Module data channel communication failure)

----------------------------------------------------------------

bad-crypto

Crypto operation failed during IPsec processing

This counter increments when the device attempts to encrypt or decrypt an IPsec packet and the operation fails. The failure is detected after the packet is submitted to the crypto subsystem and an error status is returned. This can occur during both inbound (decryption) and outbound (encryption) IPsec processing. The counter applies to all IPsec traffic including site-to-site VPN tunnels, remote access VPN, and SSL VPN connections. On platforms with hardware crypto accelerators (such as FPR 3100, 4200, and ASA 5585 series), failures may indicate issues with the accelerator chip (Nitrox or Cavium engines). On virtual platforms (ASAv, FTDv), failures typically indicate software crypto engine problems. A small number of these drops may be benign and occur during transient conditions such as SA rekey operations or brief resource contention. Persistent or rapidly increasing counters indicate a more serious problem that requires investigation.

Recommendation:

Enable syslog message 402123 to capture detailed information about each crypto failure, including the error type, error code, and the specific crypto command that failed. This syslog will indicate whether the error is hardware-related or software-related. Check the global IPsec error counter using 'show ipsec stats' — the 'decrypt errors' and 'encrypt errors' fields will show cumulative failures across all tunnels. If a specific tunnel is affected, use 'show crypto ipsec sa detail' to view per-SA error statistics. For hardware-related errors on platforms with crypto accelerators, verify the accelerator status with 'show crypto accelerator statistics'. If errors are persistent and affecting traffic, consider these actions: (1) On FPR 3100/4200 platforms experiencing hardware offload issues, disable IPsec flow offload with 'no flow-offload-ipsec' as a temporary workaround. (2) Check for known defects affecting your platform and software version, particularly those related to crypto hardware. (3) If the device is under heavy crypto load, monitor for resource exhaustion. (4) For SSL VPN failures, verify that certificates use supported key sizes and signature algorithms. If the counter increments continuously and affects production traffic, or if syslog 402123 reports hardware accelerator errors, contact Cisco TAC for further diagnosis as the device may require servicing or a software upgrade.

Syslogs:

402123

----------------------------------------------------------------

bad-ipsec-natt

Invalid NAT-T Packet Structure

The device received a packet on an IPsec tunnel that negotiated NAT Traversal (NAT-T), but the packet structure is invalid. This occurs in two situations: the packet is not UDP or is not addressed to the standard NAT-T destination port (UDP 4500), or the UDP payload is too short to contain a valid ESP header. When IPsec peers negotiate NAT-T during IKE Phase 1, all subsequent ESP traffic must be encapsulated in UDP port 4500 to traverse NAT devices. This counter increments when packets arrive on a NAT-T tunnel but violate these structural requirements, preventing the device from extracting the Security Parameter Index (SPI) needed to identify the correct security association.

Recommendation:

Capture traffic on the outside interface to identify the source and characteristics of the malformed packets. Verify that any intermediate NAT devices or firewalls between the IPsec peers are not modifying or fragmenting NAT-T packets. Check for network corruption if drops occur sporadically. If drops are persistent from a specific peer, verify the peer's NAT-T implementation is correctly encapsulating ESP in UDP port 4500 with proper header lengths. Occasional drops may indicate port scanning or malformed packets from non-VPN sources and can typically be ignored if the tunnel remains functional. If the tunnel is down and this counter is incrementing, verify NAT-T negotiation completed successfully using 'show crypto ipsec sa detail' and confirm UDP 4500 is permitted through any intermediate security devices.

Syslogs:

None

----------------------------------------------------------------

bad-ipsec-prot

IPsec packet with wrong protocol type

The device received a packet on an established IPsec tunnel that does not use the negotiated encapsulation protocol. IPsec tunnels negotiate either ESP (Encapsulating Security Payload, protocol 50) or AH (Authentication Header, protocol 51) during tunnel establishment. This counter increments when the device receives a packet that should be IPsec-protected but arrives with a different protocol number—indicating the remote peer is sending traffic that does not match the negotiated security policy. This typically occurs due to: (1) configuration mismatch between peers where one side expects ESP and the other sends a different protocol, (2) an intermediate device modifying or corrupting the protocol field, (3) internal state inconsistencies after tunnel rekey or failover events, or (4) specific platform scenarios such as route-based VPNs with ECMP and NAT-T where routing changes can cause packets to arrive on the wrong interface or context. Syslog 402115 accompanies this drop and identifies the actual protocol received versus the expected protocol.

Recommendation:

Check syslog 402115 to identify the actual protocol number received and the source/destination addresses. Verify that both IPsec peers have matching IPsec proposals configured—specifically that both sides negotiate the same encapsulation protocol (ESP or AH). Review the IPsec security association details using 'show crypto ipsec sa' to confirm the negotiated parameters match on both endpoints. If the drops occur after tunnel rekey or failover events, this may indicate a known issue (CSCwc95290) where internal state becomes inconsistent; upgrading to a fixed software version resolves this. For route-based VPN deployments using ECMP with NAT-T, verify that routing is stable and packets consistently arrive on the correct tunnel interface (CSCwf31117). If drops persist with correct peer configuration, capture traffic on both sides to determine whether an intermediate device is modifying packets or if there is asymmetric routing causing packets to bypass IPsec encapsulation. Occasional drops during tunnel establishment or teardown are typically benign; sustained drops indicate a configuration or interoperability problem requiring peer-side investigation.

Syslogs:

402115

----------------------------------------------------------------

bad-ipsec-udp

Invalid IPsec-over-UDP Packet Length

The device received an IPsec-over-UDP encapsulated packet where the UDP payload length is smaller than the minimum required for a valid ESP packet. IPsec-over-UDP is a remote access VPN feature that encapsulates ESP traffic in UDP on a custom negotiated port (not the standard NAT-T port 4500). Each IPsec-over-UDP packet must contain at least the ESP header, initialization vector, encrypted payload, and authentication trailer. This counter increments when the UDP payload is too short to contain these required components, indicating either packet truncation, corruption in transit, or a misconfigured or misbehaving VPN client.

Recommendation:

Capture and analyze the dropped traffic to identify the source. Check whether the remote VPN client software is up to date and properly configured for IPsec-over-UDP. Verify that no intermediate devices (firewalls, proxies, or NAT gateways) are fragmenting or truncating UDP packets. If the traffic is not legitimate VPN traffic, investigate whether an attacker is sending malformed packets to the IPsec-over-UDP port. Compare the UDP payload length in the captured packets against the expected IPsec overhead for the negotiated encryption and authentication algorithms. If the issue persists with legitimate clients, check for MTU mismatches or Path MTU Discovery problems that could cause fragmentation. Note that this counter is specific to IPsec-over-UDP (custom port); standard NAT-T traffic on UDP port 4500 uses a different validation path and would trigger the bad-ipsec-natt counter instead.

Syslogs:

None

----------------------------------------------------------------

bad-tcp-cksum

Bad TCP Checksum

The appliance received a TCP packet whose computed checksum does not match the checksum value in the TCP header. This drop occurs only when TCP checksum verification is enabled in a tcp-map policy applied to the traffic. The appliance computes the checksum over the TCP header and payload, and if it does not match the header's checksum field, the packet is dropped. This verification is automatically triggered when traffic undergoes TCP normalization, which occurs when Layer 7 inspection is enabled or when traffic is redirected to service modules (such as IPS, Firepower, or CX). Checksum mismatches can result from legitimate packet corruption (faulty cables, network equipment, or electromagnetic interference), hardware checksum offload issues (particularly on virtual platforms or with VPN NAT traversal), or malicious traffic. In environments using service modules or VPN with NAT traversal (UDP port 4500), false positives have been observed where valid packets are incorrectly flagged due to checksum computation timing or hardware offload state.

Recommendation:

First, use packet capture to examine the dropped packets and identify their source. If drops are isolated to specific endpoints, investigate those systems for hardware issues (network interface cards, cables) or misconfigurations. If drops occur broadly after enabling IPS or other service modules, or when using VPN with NAT traversal, verify that you are running a current software version, as several defects have been resolved in this area. To disable checksum verification, remove the 'checksum-verification' command from the tcp-map policy, or configure TCP state bypass for the affected traffic class. Note that disabling verification reduces protection against corrupted or malicious packets. If drops persist on virtual platforms (ASAv, FTDv) or with VPN traffic, contact Cisco TAC, as platform-specific checksum offload issues may require software updates or configuration adjustments.

Syslogs:

302014 (TCP connection teardown with 'TCP invalid SYN' may appear when SYN packets are dropped due to bad checksums)

----------------------------------------------------------------

bad-tcp-flags

Bad TCP Flags

The appliance received a TCP packet with an invalid combination of control flags in the TCP header. The TCP normalization engine validates flag combinations against a table of known-invalid patterns before processing the packet. Common examples include packets with both SYN and FIN flags set simultaneously, packets with no flags set (NULL scan), or packets with all flags set (XMAS scan). These flag combinations violate TCP protocol specifications and are often associated with network scanning tools, evasion attempts, or packet corruption. The appliance drops these packets during the normalization phase to protect against malformed traffic and potential attacks.

Recommendation:

Use packet capture to examine the dropped packets and identify the specific flag combination and source. If the traffic originates from a legitimate application or network device, the device may be malfunctioning or sending malformed packets due to a software bug—contact the vendor. If the source is external or untrusted, this may indicate a port scan (such as XMAS or NULL scans used by tools like nmap) or an active attack attempt; investigate the source IP and consider blocking it if the behavior persists. If the traffic appears to be corrupted in transit, check for network infrastructure issues such as faulty cables, switches, or interface errors. Occasional drops from random sources are typically benign and represent background Internet noise. Sustained drops from specific sources warrant investigation.

Syslogs:

None

----------------------------------------------------------------

blks-export-lim

Packet dropped due to block export limit to inspection engine

This counter increments when a packet cannot be sent to the threat detection engine (Snort) because the system has reached its limit for exporting packet data blocks. The data plane maintains a threshold (typically 80% of available blocks) to prevent resource exhaustion when queuing packets for inspection. When this threshold is exceeded, new packets destined for inspection are dropped rather than queued. This condition typically occurs during sustained high traffic loads when the inspection engine cannot process packets as quickly as they arrive, causing blocks to accumulate in the transmission queues. Unlike the snort-busy counters which indicate the inspection engine itself is overloaded, this counter specifically tracks drops due to the data plane's block export capacity being reached. The behavior varies by interface type: inline-tap and passive interfaces always drop packets when this limit is hit, while routed and inline interfaces may bypass inspection if fail-open policies are configured.

Recommendation:

Check current block utilization with 'show blocks' and identify what is holding blocks with 'show blocks old'. Look for 'TO INSPECT SNORT' entries which indicate blocks queued for inspection. Review inspection engine health with 'show asp inspect-dp snort queues' to see if transmit queues are full or approaching their data limits. If queues show sustained high utilization, the inspection engine may be undersized for the traffic load. Consider: (1) reviewing and optimizing intrusion policies to reduce inspection overhead, (2) enabling fail-open policies on inline interfaces if dropping traffic is unacceptable ('set connection advanced-options fail-open-busy' in inline set configuration), (3) increasing inspection engine resources if running on a virtual platform, or (4) using traffic profiling to identify which flows are consuming the most inspection resources. If this counter increments during traffic spikes but the inspection engine is healthy, it may indicate normal backpressure protection. Persistent increments with low traffic suggest a resource leak or configuration issue—contact Cisco TAC with a troubleshooting bundle.

Syslogs:

None

----------------------------------------------------------------

blks-export-lim-fp

Packet dropped due to Snort inspection block export limit exceeded

This counter increments when a packet requiring Snort inspection cannot be sent to the inspection engine because the system has reached the maximum number of memory blocks that can be queued for export to Snort (80% of the configured limit). This occurs when Snort is unable to process packets quickly enough, causing the export queue to fill. The counter specifically tracks drops for flows using full TCP proxy inspection. The packet disposition depends on the interface type and fail-open configuration: inline-tap and passive interfaces always drop the packet, while inline non-tap and routed interfaces may bypass inspection if fail-open on busy is configured.

Recommendation:

Use 'show blocks old' to identify which subsystem is holding blocks and preventing export. Check Snort instance health with 'show asp inspect-dp snort queues' to verify queue utilization and whether Snort instances are responding. Review 'show asp inspect-dp snort counters summary queues' for transmit queue backpressure indicators. If Snort is overloaded, consider prefiltering high-volume traffic (such as fragmented syslog traffic) using access rules or prefilter policies to reduce inspection load. If fail-open behavior is desired during Snort overload conditions, configure 'set connection advanced-options fail-open' in the access control policy. For persistent issues with block exhaustion, collect a troubleshoot bundle and contact Cisco TAC.

Syslogs:

None.

----------------------------------------------------------------

blks-export-lim-inline-flow

Packet dropped due to block memory export limit on inline-tap or passive interface

This counter increments when a packet destined for Snort inspection cannot be sent because block memory consumption has exceeded the configured threshold (typically 80% of available blocks for that size class), and the packet arrived on an inline-tap or passive interface. Block memory is used to buffer packets throughout the system. When usage is too high, the system prevents exporting additional blocks to Snort to avoid exhausting memory resources. On inline-tap and passive interfaces, packets are automatically dropped when this limit is reached, regardless of fail-open configuration, because these interface types cannot bypass inspection by design.

Recommendation:

Check block memory utilization with 'show blocks' to identify which block sizes are depleted or approaching limits. Look for the 'CNT' (current count) approaching 'MAX' values. If block depletion is occurring, investigate what is consuming blocks: check for high traffic rates, large numbers of concurrent connections, or features that buffer packets (such as TCP normalization, fragmentation reassembly, or VPN). Consider whether traffic patterns justify the memory consumption or if there is a resource leak. If this counter increments frequently during normal operation, the system may be undersized for the traffic load. For inline-tap interfaces used for monitoring, evaluate whether the tap configuration is appropriate for the traffic volume. This drop is a protective mechanism to prevent complete memory exhaustion.

Syslogs:

None directly associated. Related: %ASA-3-321007 (system low on free memory blocks)

----------------------------------------------------------------

blks-export-lim-no-app-info

Packet dropped due to missing inspection flow state during buffer exhaustion

This counter increments when a packet requiring Snort inspection is dropped because the system cannot locate the internal flow tracking information needed for inspection, and packet buffer usage has exceeded 80% of capacity. This occurs on FTD platforms when the communication queue between the data plane and Snort inspection engine becomes saturated, preventing new packets from being queued for inspection. The missing flow state combined with buffer pressure triggers a protective drop to prevent complete buffer depletion. This condition typically appears under sustained high traffic loads when Snort cannot process packets as quickly as they arrive, causing the Producer-Data-Transport-Service (PDTS) queue to fill. The 80% threshold acts as a safety mechanism—once buffer usage crosses this point, packets without valid inspection state are dropped rather than queued.

Recommendation:

Check Snort inspection queue health with 'show asp inspect-dp snort counters summary queues' and look for non-zero TxQ-Full or TxQ-Data-Limit counters indicating Snort overload. Verify Snort instance health with 'show snort statistics' and 'show snort instances' to identify CPU or memory saturation. Review 'show blocks' output to confirm buffer pool utilization—sustained usage above 80% indicates the system is under resource pressure. If drops persist, consider: (1) reducing inspection scope by tuning access control policies to bypass low-risk traffic, (2) increasing Snort instance count if CPU headroom exists, or (3) enabling fail-open policies if brief inspection bypasses are acceptable during overload. If buffer depletion occurs (blocks CNT approaching MAX), a reload may be required to recover. Contact TAC if drops continue after tuning, especially if accompanied by incrementing WRITE_FAILED counters in 'show daq counters', which may indicate defect CSCwm40721.

Syslogs:

447001, 321007

----------------------------------------------------------------

block-no-prepend

Insufficient buffer headroom to add inspection header

This counter increments when the system cannot prepend a required protocol header to a packet because the packet buffer lacks sufficient space at the beginning. This occurs on Firepower Threat Defense (FTD) platforms when the dataplane needs to add metadata headers before sending packets to the Snort inspection engine, but the packet buffer was allocated without adequate headroom. The packet is dropped because it cannot be forwarded for inspection without the required header information.

Recommendation:

This counter indicates a software defect in packet buffer allocation. It should not occur during normal operation. If you observe this counter incrementing, collect a troubleshooting bundle and contact Cisco TAC. Include the output of 'show asp drop' and 'show traffic' to help identify which traffic patterns trigger the condition. This is not caused by configuration issues or network conditions—it reflects an internal buffer management problem that requires engineering investigation.

Syslogs:

None.

----------------------------------------------------------------

bvi-missing-nameif

Bridge Virtual Interface Missing Name

This counter increments when traffic arrives on a physical interface that belongs to a bridge group and needs to route to a different bridge group or to a Layer 3 interface, but the Bridge Virtual Interface (BVI) for the ingress bridge group does not have a nameif configured. Bridge groups require a named BVI to enable routing capability; without a nameif, traffic is confined to Layer 2 switching within the bridge group members. This drop occurs in routed firewall mode when Integrated Routing and Bridging (IRB) is configured but incomplete. Traffic destined to or originating from the firewall itself is not affected by this check.

Recommendation:

Configure a nameif on the Bridge Virtual Interface for the ingress bridge group. Enter interface configuration mode for the BVI (for example, 'interface BVI1'), assign a nameif (for example, 'nameif inside-bridge'), and configure an IP address. Verify the configuration with 'show nameif' and 'show interface' to confirm the BVI is operational. If traffic should remain Layer 2 only within the bridge group and not route to other networks, this drop is expected behavior and no action is needed. If you are migrating from transparent mode to routed mode with bridge groups, ensure all BVIs are fully configured before enabling routing.

Syslogs:

None

----------------------------------------------------------------

bvi-unsupported-packet

Unsupported broadcast or multicast packet on Bridge Virtual Interface

This counter increments when a broadcast or multicast packet is sent to a Bridge Virtual Interface (BVI) but the packet type is not supported for flooding across bridge group members. BVI interfaces only support flooding for ARP requests and DHCPv4 broadcast packets (UDP ports 67/68). All other broadcast and multicast traffic types—including IPv6 Neighbor Discovery multicasts, routing protocol hellos (OSPF, EIGRP, PIM), and general multicast data—are dropped when destined to the BVI itself. This is expected behavior in transparent firewall mode with bridge groups. Unicast traffic with a known destination MAC is forwarded normally based on Layer 2 MAC learning.

Recommendation:

This drop is typically benign and reflects the design limitation of BVI interfaces. If you see this counter incrementing, verify what type of traffic is being dropped using packet captures or 'capture asp-drop bvi-unsupported-packet'. Common scenarios include: (1) Routing protocol multicasts—bridge group member interfaces should not participate in multicast routing protocols like PIM or IGMP; ensure the BVI interface has a nameif configured and that routing protocols are enabled only on the BVI, not on member interfaces. (2) IPv6 multicast traffic—IPv6 Neighbor Discovery and other IPv6 multicast is handled through separate mechanisms; verify IPv6 is properly configured on the BVI. (3) Broadcast traffic from unsupported protocols—only ARP and DHCPv4 broadcasts are flooded; other broadcast protocols are not supported on BVI interfaces. If legitimate traffic is being dropped, consider whether the traffic should be routed through the BVI (Layer 3) rather than bridged (Layer 2), or whether the deployment requires a different interface configuration.

Syslogs:

None

----------------------------------------------------------------

captive-portal

Captive portal redirect already sent

This counter increments when traffic arrives for a session that has already received a captive portal authentication redirect. When an identity policy with active authentication is configured, the first HTTP request from an unauthenticated user triggers a redirect to the captive portal login page. The firewall marks that session as having received the redirect. Any subsequent packets on the same session before authentication completes are dropped and the connection is reset to force the client to follow the redirect. This is normal behavior during the authentication process and prevents the original connection from continuing while the user is being redirected to authenticate.

Recommendation:

This drop is expected during captive portal authentication workflows and typically indicates normal operation. The counter will increment for packets that arrive after the redirect is sent but before the user completes authentication. If you see a high rate of these drops, verify that: (1) clients are successfully reaching the captive portal login page and completing authentication, (2) the captive portal configuration includes the correct authentication port and hostname, (3) identity policy rules with active authentication are correctly applied to the traffic, and (4) there are no network issues preventing clients from accessing the authentication portal. Use packet tracer to examine the full authentication flow and verify the redirect is being generated correctly. If users report being unable to authenticate or being repeatedly redirected, collect debugs and contact Cisco TAC.

Syslogs:

None.

----------------------------------------------------------------

channel-closed

Interface unavailable for internal processing path

This counter increments when a packet arrives on an internal processing path (cluster control link, high-availability link, or loopback reinjection) but the associated interface is down, not fully initialized, or has been removed from configuration. This most commonly occurs during cluster or HA topology changes, such as when a cluster control link interface transitions to a down state while cluster traffic is still being received, or when an HA link interface is administratively shut down. It can also occur during flow creation if the egress interface becomes unavailable between the time a flow is classified and when its processing pipeline is constructed. On multi-core systems, this may happen when one core removes or shuts down an interface while another core is still processing packets destined for that interface.

Recommendation:

Check the status of cluster control link (CCL) and HA link interfaces using 'show interface' and 'show cluster info'. If you are running clustering, verify that the CCL interface is up on all cluster members and that cluster formation is stable. For HA configurations, confirm that the HA link interface is operational on both units. Transient increments during interface state changes (such as during a 'no shutdown' or cluster join operation) are normal and expected. Sustained or rapidly increasing counters indicate an interface flapping or a configuration mismatch where traffic is being directed to an interface that is persistently down. If the counter increments during normal operation without corresponding interface state changes, collect 'show tech-support' and contact Cisco TAC.

Syslogs:

None

----------------------------------------------------------------

cluster-app-no-forward

Application packet dropped during cluster member initialization

This counter increments when a cluster member drops a packet because the member's data interfaces are not yet ready to forward traffic, and the packet type is not safe to forward to other cluster members. This occurs during the cluster join process or when data interfaces are initializing. The system identifies certain traffic types—specifically LISP control protocol traffic (UDP port 4342) and packets arriving on internal network layer protocol interfaces—as unsuitable for inter-cluster forwarding. When such packets arrive before the member's data interfaces are fully operational, they are dropped rather than being sent to the flow director for owner determination.

Recommendation:

This counter is typically seen during normal cluster member bootstrap and join operations. If you observe this counter incrementing: (1) Verify that cluster members are successfully completing the join process and that data interfaces transition to the ready state—use 'show cluster info' to check member status. (2) If members remain stuck in a joining state with this counter increasing, check for interface configuration mismatches between the control node and joining members, or issues with the cluster control link. (3) For LISP-enabled deployments, ensure LISP control traffic is not being unexpectedly routed through cluster members during initialization. (4) Occasional increments during member joins are normal and expected; sustained or high counts indicate a problem with cluster member initialization that should be investigated with TAC assistance.

Syslogs:

None. Related cluster join issues may generate %ASA-3-747033 (interface mismatch) or %ASA-3-747030 (interface health check failure).

----------------------------------------------------------------

cluster-bad-ifc-goid-in-trailer

Cluster member cannot resolve interface identifier for hardware-decrypted packet

A cluster member received a packet that was decrypted by hardware crypto acceleration on another cluster member and forwarded over the cluster control link, but the interface identifier embedded in the packet metadata does not match any known interface on the receiving unit. This occurs when cluster members have inconsistent interface state due to incomplete synchronization of global object identifiers (GOIDs) during configuration changes, unit failures, or cluster membership transitions. The receiving unit cannot determine which interface should process the decrypted packet and drops it. This counter is specific to platforms with hardware IPsec offload capability (Secure Firewall 1200, 3100, 4200, 6100) running in cluster mode with crypto offload enabled.

Recommendation:

Check for cluster synchronization issues: verify all cluster members show consistent interface configurations with 'show interface' and 'show cluster info'. If the counter increments during or shortly after configuration changes (especially interface modifications), policy deployments, or cluster membership events (unit joins/leaves), the GOID tables may be out of sync. Reload the affected cluster member to force full resynchronization. If the problem persists after reload, disable and re-enable clustering on the affected unit. This issue was addressed in ASA 9.6 and later releases; ensure all cluster members run the same software version. If the counter increments steadily during normal operation without configuration changes, collect 'show tech-support' and 'show asp drop' from all cluster members and contact Cisco TAC, as this may indicate a software defect or hardware crypto offload issue.

Syslogs:

747012, 747014

----------------------------------------------------------------

cluster-bad-tp-pkt

Cluster transport protocol packet validation failed

The device received a packet with the special TTL value (254) that indicates a cluster transport protocol message, but the packet failed validation checks. This drop occurs when clustering is not enabled on the device, or when the packet is not UDP, or when the destination port is not 4193 (the cluster transport protocol port). These packets are internal control messages used for communication between cluster members over the Cluster Control Link (CCL). This counter typically increments when a device that is not part of a cluster receives stray cluster protocol packets, or when malformed cluster packets arrive on the CCL interface.

Recommendation:

If clustering is not configured on this device, these drops are expected and benign—they indicate the device is correctly rejecting cluster protocol packets that should not be sent to it. Verify that no other devices are misconfigured to send cluster traffic to this device's IP address. If clustering is enabled, verify that the Cluster Control Link interface is properly configured and that cluster members are using the correct transport protocol (UDP port 4193). Check for network issues that might corrupt cluster packets in transit, such as MTU mismatches or middleboxes that modify packet headers. Use 'show cluster info' to verify cluster status and 'show interface' on the CCL interface to check for errors. If drops persist on a properly configured cluster member, collect packet captures on the CCL interface to identify the source of malformed packets.

Syslogs:

None.

----------------------------------------------------------------

cluster-bad-trailer

Cluster packet forwarding trailer validation failed

The device received a packet on the Cluster Control Link (CCL) from another cluster member, but the cluster packet forwarding trailer attached to the packet failed validation. When cluster members forward packets to each other, they append a metadata trailer containing flow ownership information, interface identifiers, and other cluster-specific data. This counter increments when the trailer is missing, corrupted, has an invalid magic number, contains an unsupported version, or cannot be located at the expected position based on the IP packet length. This typically occurs due to packet corruption on the CCL interface, version mismatches between cluster members running incompatible software releases, or malformed packets reaching the CCL (potentially from misconfigured network equipment or security attacks). The affected packets are dropped to prevent processing of invalid cluster metadata that could lead to incorrect forwarding decisions or system instability.

Recommendation:

Check for physical layer issues on the Cluster Control Link interface (cable problems, interface errors, CRC errors). Verify all cluster members are running compatible software versions—mixing incompatible releases can cause trailer format mismatches. Review the cluster topology to ensure no non-cluster traffic is being forwarded to the CCL interface; the CCL should be on a dedicated, isolated network segment. If drops persist, capture traffic on the CCL interface and examine packet structure. Occasional drops may be benign (transient corruption), but sustained or increasing counters indicate a configuration or hardware problem requiring immediate attention. If the cluster is experiencing instability or members are failing to join, contact Cisco TAC with the output of 'show asp drop', 'show cluster info', and a packet capture from the CCL interface.

Syslogs:

None.

----------------------------------------------------------------

cluster-bad-trailer-tlv

Cluster CCL packet has malformed or unrecognized trailer option

This counter increments when a cluster member receives a packet on the Cluster Control Link (CCL) interface with a malformed or unrecognized optional field in the cluster packet trailer. When cluster members forward packets to each other, they append metadata trailers containing information such as flow ownership, VPN direction, and interface details. These trailers can include optional Type-Length-Value (TLV) fields for extended metadata. This drop occurs when the receiving unit encounters a TLV option type it does not recognize or cannot parse correctly. Common causes include software version mismatches between cluster members (where newer members use trailer options not understood by older members), memory corruption affecting the trailer structure, or network issues causing packet truncation or corruption on the CCL link.

Recommendation:

First, verify that all cluster members are running identical software versions using 'show cluster info' and 'show version'. Mixed-version clusters during upgrades can trigger this drop temporarily. If versions match, check the CCL interface health with 'show interface' for the cluster link—look for CRC errors, input errors, or link flaps that could corrupt packets in transit. Examine 'show cluster info packets' for other CCL-related errors. If drops persist with matching versions and a healthy CCL link, collect packet captures on the CCL interface to identify which cluster member is sending malformed trailers, then investigate that unit for potential memory corruption or software defects. Contact Cisco TAC if the issue continues, providing 'show tech-support' output and CCL packet captures from both sending and receiving units.

Syslogs:

None.

----------------------------------------------------------------

cluster-ccl-backup

Cluster data packet received on backup unit

A data packet was received over the cluster control link on a unit that is designated as the backup for this flow, but the packet should have been received on the flow owner or director unit instead. In a properly functioning cluster, data packets are forwarded to the owner unit that maintains the full connection state, while backup units only hold stub flows for failover purposes. This drop indicates a cluster forwarding inconsistency where packets are being misdirected to a backup unit that cannot process them. Common triggers include: cluster topology changes when a unit leaves or joins and forwarding flows are not yet updated to point to the new owner; dynamic NAT scenarios where the local unit becomes the new PAT pool owner but stale forwarding flows still point to the old owner; timing issues where ICMP replies or secondary flow packets arrive at the director before flow ownership is fully established; and director or backup flow state becoming stale after ownership changes. This counter is most often seen during cluster membership transitions, with interface PAT configurations, or in multi-site deployments with director localization enabled.

Recommendation:

Check for recent cluster membership changes using 'show cluster info' and 'show cluster history'. If the counter increments during or immediately after a unit leaving or joining, the drops are typically transient as the cluster converges on new flow ownership. For persistent drops, examine 'show asp drop' frame counters and correlate with 'show conn' output to identify affected flows. If drops occur with dynamic NAT or interface PAT, verify NAT pool ownership is stable across the cluster. Clear stale connections with 'clear conn address <ip>' for the affected flows. In multi-site clusters with localization, verify director assignments are consistent. If drops persist without topology changes, collect 'show tech-support' and contact Cisco TAC, as this may indicate a flow synchronization defect requiring software upgrade.

Syslogs:

None.

----------------------------------------------------------------

cluster-ccl-bad-unxlate-redirect

Cluster member dropped NAT redirect packet due to stale flow state

This drop occurs in clustered deployments using dynamic PAT when a cluster member receives a reverse-direction packet redirect from another member, but the receiving member has outdated information about which member owns the PAT pool for that connection. In a cluster, PAT pool ownership is distributed across members, and each member must know which peer owns each portion of the address pool. When return traffic arrives at a member that doesn't own the flow, it normally redirects the packet to the correct owner. However, if the receiving member has a placeholder (stub) flow entry pointing to a different owner than the one that sent the redirect, this indicates the sender's pool ownership table is out of sync. The packet is dropped to prevent redirect loops where members continuously bounce packets between each other. This typically happens during cluster membership changes (a unit joining, leaving, or failing), during the brief period when pool ownership is being redistributed but not all members have received the updated assignments. It can also occur with DNS responses, ICMP replies, or other return traffic when the original outbound connection was established on one member but the return path arrives at a different member.

Recommendation:

This counter incrementing during or immediately after a cluster membership change (unit join, leave, or failure) is expected and benign—the cluster is self-correcting by dropping packets that would cause redirect storms while pool ownership synchronizes. If the counter increments continuously during steady-state operation with no topology changes, this indicates a persistent pool ownership synchronization problem. Check for: (1) cluster control link (CCL) health and packet loss using 'show cluster info' and interface statistics on the CCL interface; (2) asymmetric routing where return traffic consistently arrives at members other than the flow owner; (3) whether the issue correlates with specific traffic types like DNS or from-the-box traffic. If drops persist without cluster changes and affect production traffic, collect 'show asp drop', 'show cluster info', 'show xlate', and packet captures on the CCL interface, then contact Cisco TAC. In environments with frequent cluster topology changes, consider whether the cluster design matches the traffic pattern—highly asymmetric traffic may benefit from director localization or different load distribution settings.

Syslogs:

None.

----------------------------------------------------------------

cluster-ccl-bad-unxlate-redirect-backup

Cluster member received NAT untranslate redirect for backup stub flow

This counter increments when a cluster member that owns a dynamic PAT pool receives a packet redirect for NAT untranslation, but the matching flow exists only as a backup stub rather than an active translation. In cluster deployments, PAT pool ownership is distributed across members. When return traffic arrives at a member that did not create the original translation, the packet is redirected to the PAT pool owner for untranslation. Normally, the pool owner has either the active translation or a director flow. This drop occurs when the pool owner finds only a backup stub flow, indicating a synchronization mismatch between the flow owner and backup state. This typically happens during cluster topology changes such as member failure, rejoin, or master re-election, when backup flows may temporarily exist without corresponding active translations. The condition is transient and expected during these events as the cluster re-synchronizes state.

Recommendation:

This counter incrementing during cluster member failures, rejoins, or topology changes is normal and does not require action. The affected connections will typically recover through retransmission. However, if this counter increments continuously during stable cluster operation (no member changes), it indicates a timing or synchronization issue between cluster members. In that case: verify all cluster members are running the same software version, check for cluster control link (CCL) latency or packet loss, review recent configuration changes to NAT rules (especially interface PAT or dynamic PAT pools), and monitor whether specific traffic types are affected (such as DNS queries). If the counter increments persistently without topology changes, collect troubleshooting bundles from all cluster members and contact Cisco TAC, as this may indicate a software defect requiring investigation.

Syslogs:

None.

----------------------------------------------------------------

cluster-ccl-cfull-sent

Cluster data packet dropped after full flow created

A data packet was forwarded to this cluster unit over the Cluster Control Link (CCL), but by the time it arrived, this unit had already been promoted to flow owner and created the full connection state. The forwarded packet is no longer needed because the unit can now process traffic for this connection directly. This occurs during normal cluster flow ownership transitions when a unit that initially forwarded packets to another owner is elected to become the new owner itself. The timing window between sending the query and receiving the ownership response allows this race condition.

Recommendation:

This is expected behavior during cluster operation and does not indicate a problem. The counter tracks packets that arrive slightly out of sequence during flow ownership changes. If this counter increments at a high rate continuously, verify that cluster control link connectivity is stable and that cluster units are not experiencing frequent role changes or instability. Check 'show cluster info' to confirm all units are healthy and synchronized.

Syslogs:

None.

----------------------------------------------------------------

cluster-ccl-unknown

Cluster CCL packet with invalid owner

A packet was received over the cluster control link without a matching flow, and the assigned flow owner specified in the packet is not a valid cluster member. This occurs when the owner member ID references a unit that has left the cluster, is in a disabled state, or was never part of the cluster topology. The receiving unit cannot forward the packet because the intended owner is unreachable or unknown.

Recommendation:

This drop is typically transient and occurs during cluster membership changes (unit leaving, failing, or being removed). If persistent, verify cluster health with 'show cluster info' to confirm all expected members are present and active. Check for recent cluster membership events in syslogs (747xxx series). If a specific member repeatedly appears as an invalid owner, investigate why that unit left the cluster or is in a disabled state. Occasional drops during topology changes are normal; sustained drops indicate a cluster synchronization or membership problem that may require reloading affected units or verifying cluster control link connectivity.

Syslogs:

747006 (cluster state changes), 747026 (member rejected), 747042 (unknown member)

----------------------------------------------------------------

cluster-ccl-unknown-stub

Cluster CCL packet with stub flow but unknown owner

A cluster data packet was received over the Cluster Control Link (CCL) and matched an existing stub flow, but the flow owner identifier was invalid or unknown. Stub flows are temporary placeholder flows created by the cluster director unit while determining which cluster member should own a connection. This drop occurs when the ownership information becomes inconsistent—typically during cluster topology changes such as member join/leave operations, flow redistribution, or when cluster members are running incompatible consistent-hash versions. This counter is most commonly seen in clusters with VPN (IPsec/IKEv2) sessions, particularly in multi-node Secure Gateway deployments during redistribution or node removal events.

Recommendation:

This drop is usually transient and occurs during cluster state transitions. If the counter increments continuously during stable cluster operation, verify that all cluster members are running the same software version and that the cluster topology is stable (no flapping members). For VPN-related drops, check that VPN sessions are properly distributed and that flow ownership is correctly established after topology changes. If drops persist, collect 'show cluster info', 'show asp table cluster chash', and 'show asp drop' output, and contact Cisco TAC. Known issues have been resolved in ASA 9.9.2, 9.10.1, and later releases—ensure you are running a current software version.

Syslogs:

None.

----------------------------------------------------------------

cluster-data-node-data-ifc-not-ready

Data node interface not ready during cluster join

A data node received a packet that should be processed locally, but the node's data interfaces have not yet completed synchronization with the control node during the cluster join process. When a data node joins or rejoins a cluster, there is a brief window where the node is partially joined but its Layer 3 data interfaces are not yet fully operational. During this transition period, the node cannot own connections on these interfaces and must drop packets destined for local processing. This counter increments for traffic arriving on Layer 3 interfaces (excluding management-only, cluster control link, and loopback interfaces) before the data node completes its join sequence and becomes fully active in the cluster. The condition is temporary and resolves automatically once interface synchronization completes and the node transitions to the fully joined state.

Recommendation:

This counter is informational and indicates normal cluster join behavior. Drops are expected during the brief period when a data node is joining or rejoining the cluster. Monitor the cluster join process using 'show cluster info' to verify the node successfully transitions to a fully joined state. If drops persist after the node shows as fully joined, or if nodes repeatedly fail to complete the join process, investigate potential causes: verify all data interfaces are up and healthy on both control and data nodes, check for interface configuration mismatches between cluster members, review cluster health-check status, and examine interface health-check failures in 'show cluster history'. For nodes that fail to join, check for underlying issues such as EtherChannel/port-channel negotiation problems, LACP failures, or interface state mismatches. Persistent join failures may require reviewing cluster configuration consistency and physical connectivity.

Syslogs:

747030, 747033

----------------------------------------------------------------

cluster-data-node-ignored

Multicast control packet dropped on cluster data node

A multicast routing control packet was received on a Layer 3 cluster interface when the unit was operating as a data node. In Layer 3 (individual interface mode) clustering with multicast routing enabled, only the control node processes multicast routing protocol packets to maintain consistent multicast state across the cluster. This counter increments when data nodes receive and drop multicast ICMP packets, Auto-RP Announce messages (UDP 496 to 224.0.1.39), or Auto-RP Discovery messages (UDP 496 to 224.0.1.40). The control node receives and processes these same packets normally.

Recommendation:

This counter is informational and indicates expected behavior in Layer 3 cluster deployments with multicast routing. Data nodes intentionally drop multicast control traffic to prevent duplicate protocol processing and state inconsistencies. The control node handles all multicast routing protocol operations (PIM neighbor adjacencies, RP discovery, IGMP processing) for the entire cluster. No action is required unless the counter increments on the control node itself, which would indicate a configuration or role election issue. Verify cluster roles with 'show cluster info' and confirm the control node is processing multicast traffic correctly with 'show pim neighbor' and 'show mroute'.

Syslogs:

None.

----------------------------------------------------------------

cluster-dir-flow-create-fail

Cluster director failed to create stub flow due to resource exhaustion

In a cluster deployment, when a unit receives a new connection and queries the director to determine flow ownership, the director must create a lightweight stub flow to track the connection state. This counter increments when the director unit cannot allocate the stub flow due to insufficient resources. The three possible resource constraints are: available system memory, packet block extension memory, or the configured connection limit. This drop occurs only on the director unit during the flow ownership election process, before the actual connection owner creates the full flow entry.

Recommendation:

Check resource availability on the cluster director unit using 'show resource usage' to identify which limit has been reached. If connection count is at or near the configured limit, consider increasing the connection limit or investigating why connection usage is abnormally high. If memory is low, check for memory leaks or excessive connection state. This drop typically indicates the director unit is overloaded and may require capacity planning review. In a healthy cluster, director stub flows consume minimal resources and this counter should remain at zero or very low. Persistent occurrences suggest either misconfigured resource limits or an underlying issue causing resource exhaustion on the director.

Syslogs:

None

----------------------------------------------------------------

cluster-dir-invalid-ifc

Cluster director dropped queued packet due to interface removal

The cluster director queued a packet while waiting to create a flow (typically when NAT translation is involved), but before the packet could be processed, the ingress or egress interface was removed or shut down through configuration changes. When the packet was dequeued for processing, the interface validation check failed because the interface handle was no longer valid. This occurs in clustered deployments when interface configuration changes (such as 'shutdown', 'no interface', or interface removal from a redundant interface) happen while packets are waiting in the async work queue for flow creation. The timing window is typically very small, measured in milliseconds, but can occur during administrative changes to interface configuration.

Recommendation:

This counter is informational and indicates expected behavior during interface configuration changes in a cluster. The affected packets are correctly dropped because they reference interfaces that no longer exist. If you see this counter increment: (1) Correlate the timing with recent interface configuration changes (shutdown, interface removal, redundant interface modifications). (2) Verify that the interface changes were intentional. (3) If the counter increments without any configuration changes, or increments continuously, contact Cisco TAC as this may indicate an unexpected interface state issue. (4) In normal operations during planned interface changes, a small number of drops is expected and does not indicate a problem. New connections will use the updated interface configuration.

Syslogs:

None

----------------------------------------------------------------

cluster-dir-nat-changed

Cluster director NAT decision changed while packet queued

On a cluster deployment, the director node queued a packet while waiting to determine the correct NAT translation. Before the packet could be processed, the NAT policy or translation state changed, making the original NAT decision invalid. The packet is dropped because it cannot be safely processed with outdated NAT information. This occurs when NAT policy is modified (rules added, removed, or changed), when a NAT translation expires, or during policy deployment while packets are in the queue. The counter typically increments during administrative changes to NAT configuration or during normal translation timeout processing on an active cluster.

Recommendation:

This counter is informational and indicates expected behavior during NAT policy changes or translation expiration on a cluster. Brief increments during policy deployment or configuration changes are normal. If the counter increments continuously without configuration changes, verify that NAT translation timeouts are appropriate for your traffic patterns and that the cluster is not experiencing membership instability. Check for frequent NAT pool exhaustion events that might cause rapid translation churn. If drops correlate with application failures, capture the timing of NAT policy changes and consider scheduling changes during maintenance windows. For persistent issues unrelated to configuration changes, collect cluster status and NAT translation state and contact Cisco TAC.

Syslogs:

None.

----------------------------------------------------------------

cluster-dispatch-queue-fail

Cluster failed to enqueue packet into director flow work queue

On multicore platforms (Firepower 2100/4100/9300, ISA 3000) running in cluster mode, the system uses a work queue to serialize director flow creation when NAT is involved, preventing race conditions between cluster members. This counter increments when a forwarded packet requiring director flow creation cannot be added to this internal work queue. The enqueue operation can fail when the queue is full, when memory allocation for queue elements fails, or during internal lock contention. This drop is specific to clustered deployments with NAT configured and typically indicates resource exhaustion—either memory pressure or extreme connection establishment rates that exceed the queue's capacity to buffer pending flow creation requests.

Recommendation:

Check memory utilization with 'show memory' and 'show blocks' to identify allocation failures. Review cluster health with 'show cluster info' and look for signs of overload or member instability. Examine NAT configuration scale—large PAT pools or high connection rates through NAT can increase director flow creation load. If drops are persistent, verify that cluster members have sufficient CPU and memory resources for the traffic load. Check for other ASP drop counters related to memory exhaustion (such as 'no-memory' or block allocation failures). If the issue persists under normal load conditions or if accompanied by tracebacks or cluster instability, contact Cisco TAC with output from 'show asp drop', 'show memory', 'show blocks', and 'show cluster info'.

Syslogs:

None.

----------------------------------------------------------------

cluster-early-sec-chk-fail

Cluster director early security check failed

This counter increments when a cluster unit acting as the flow director performs early security policy checks on a new connection and the packet fails those checks. The director evaluates security policies before assigning flow ownership to ensure consistent enforcement across the cluster. The checks include access control list evaluation, web cache redirection policies, TCP intercept settings, and IP option handling. When any of these checks result in a deny action, the director drops the packet and increments this counter rather than forwarding it to a flow owner. This occurs only in clustered deployments during the initial packet processing for new flows, before a cluster member is elected as the flow owner.

Recommendation:

This counter is informational and indicates normal security policy enforcement in a cluster environment. The packet was correctly dropped based on your configured security policies. To determine why specific traffic is being dropped: (1) Review access control lists applied to the relevant interfaces to verify the deny rule is intentional. (2) Check for WCCP redirect configurations that may be redirecting and then dropping the traffic. (3) Verify TCP intercept settings if the dropped traffic is TCP. (4) Examine whether IP options in the packets are triggering security policies. If legitimate traffic is being dropped, adjust the security policy (ACLs, WCCP, TCP intercept) on the cluster to permit the desired flows. The drops occur on the director unit, so focus troubleshooting on director role assignment and the security policies evaluated during director processing.

Syslogs:

None.

----------------------------------------------------------------

cluster-forward-error

Failed to forward packet to cluster member over CCL

A cluster member attempted to redirect a packet to another member over the Cluster Control Link but the transmission failed. This occurs when the cluster needs to forward traffic to the member that owns the flow (based on load balancing), but cannot reach that member. Common causes include: the destination member has left the cluster or is in a disabled state, the CCL interface is down or administratively disabled, or there is a connectivity issue on the cluster control link network. This affects any traffic requiring inter-member forwarding, including VPN flows being directed to the VPN owner, fragmented packets being sent to the fragment or flow owner, and NAT translations requiring coordination with the master unit.

Recommendation:

Check cluster member status with 'show cluster info' to verify all expected members are active and joined. Verify CCL interface status on all members with 'show interface' for the cluster control link. If a member recently left or was removed, this counter may increment temporarily as in-flight packets are dropped; this is expected and should stop once the cluster converges. If the counter increments continuously during normal operation, investigate CCL connectivity (check physical link, switch configuration, and MTU settings). Review 'show cluster info packets' for CCL transmission errors. If the issue persists with all members showing as active and CCL interfaces up, contact Cisco TAC as this may indicate an internal cluster state inconsistency.

Syslogs:

747035 (CCL down causing unit to leave cluster)

----------------------------------------------------------------

cluster-frag-error

Fragment owner lookup or forwarding failed in cluster

This counter increments when a cluster member receives a fragmented packet but cannot process it due to cluster fragmentation handling errors. This occurs in two scenarios: (1) the system cannot determine which cluster member should reassemble the fragments (fragment owner lookup fails), or (2) the system identifies the correct fragment owner but cannot forward the fragment to that member over the cluster control link. In a cluster, fragmented packets are distributed to a designated 'fragment owner' based on a hash of the source IP, destination IP, and packet ID. All fragments of the same packet are sent to the same owner for reassembly. This counter typically increments during cluster membership changes (when a member leaves or joins), cluster control link issues, or when the consistent hash table used for owner selection is temporarily unavailable or corrupted.

Recommendation:

Check cluster health and membership status with 'show cluster info' and verify all expected members are present and active. Review cluster control link status and connectivity between members. If drops occur during or immediately after a cluster member leaving or joining, this is often transient as the cluster recalculates fragment ownership. Persistent drops indicate a cluster control link problem or cluster membership instability. For ongoing issues, examine 'show asp drop' frame counters for related cluster drops, check for cluster control link errors with 'show interface' for the CCL interface, and verify cluster configuration consistency across all members. If drops persist after cluster stabilization, contact Cisco TAC with cluster topology details and the timing of when drops began relative to any cluster membership changes.

Syslogs:

None.

----------------------------------------------------------------

cluster-frag-owner-query-error

Cluster fragment ownership query failed

In a cluster deployment, when a unit receives fragmented packets, it first reassembles them on the fragment owner, then must query the flow director to determine which cluster member should own the connection. This counter increments when that query process fails, either because the ownership query message to the director could not be created or sent, or because the reassembled fragment chain could not be temporarily stored back in the fragment database while awaiting the director's response. This typically occurs during cluster topology changes (such as when a member leaves), under memory pressure, or when there are collisions in the fragment database due to IP identification number reuse.

Recommendation:

Check cluster health with 'show cluster info' and verify all members are stable and communicating properly over the cluster control link. Review memory utilization with 'show memory' and 'show blocks' to identify resource exhaustion. If drops correlate with cluster membership changes, ensure the cluster is stable before troubleshooting further. For persistent issues with large or jumbo frame traffic, verify MTU settings are consistent across the cluster and that fragment reassembly parameters ('show fragment') are appropriately configured. If drops occur during normal stable operation, collect 'show asp drop' output, cluster statistics, and contact Cisco TAC for analysis.

Syslogs:

None

----------------------------------------------------------------

cluster-invalid-owner

Cluster Invalid Owner

A packet was dropped because it needed to be redirected to a specific cluster member (the flow owner), but that member is no longer valid or active in the cluster. This occurs when a cluster member has left the cluster—due to a health check failure, manual removal, reload, or upgrade—and packets arrive for flows that were owned by that departed member. The receiving unit cannot redirect the packet because the owner ID no longer corresponds to an active cluster member, and no valid backup owner is available. This is a transient condition that typically occurs during cluster membership changes or topology transitions.

Recommendation:

Small numbers of these drops during cluster member removal, reload, or upgrade are expected and benign—affected connections will be re-established by clients. Investigate if drops are sustained or occur without cluster topology changes: verify cluster health with 'show cluster info' and 'show cluster history', check for repeated member join/leave events in 'show logging | include cluster', and review interface health check status. If a specific member is flapping in and out of the cluster, troubleshoot the underlying cause (CCL link issues, interface health check failures, resource exhaustion). For persistent drops without topology changes, collect 'show asp drop' output over time and contact Cisco TAC with cluster status and logs.

Syslogs:

None.

----------------------------------------------------------------

cluster-invalid-pkt

Invalid cluster control message received

A cluster control message received over the Cluster Control Link (CCL) failed validation during parsing. This occurs when the message header contains an invalid length field that would cause the parser to read beyond the end of the received packet buffer. The entire multi-message frame is dropped when any message within it has an invalid length. This counter typically indicates corruption of cluster control traffic, which can result from network issues on the CCL interface, memory corruption on the sending unit, or software defects affecting message construction.

Recommendation:

Check the physical health of the CCL interface and cabling on both the sending and receiving cluster members. Review recent cluster membership changes or configuration updates that might correlate with the drops. If drops persist, capture traffic on the CCL interface using 'capture' with the cluster interface specified, and examine the captured packets for malformed headers or truncation. Check for any memory-related syslog messages on the cluster members. If the issue continues after verifying CCL connectivity and no obvious configuration issues exist, contact Cisco TAC with the output of 'show asp drop', 'show cluster info', and any CCL packet captures.

Syslogs:

None

----------------------------------------------------------------

cluster-ip-version-error

Cluster control link packet with mismatched EtherType and IP version

This counter increments when a packet received on the cluster control link has an inconsistency between the Ethernet frame's EtherType field and the actual IP header version. For example, the Ethernet header indicates IPv4 (EtherType 0x0800) but the IP header shows a version field other than 4, or the EtherType indicates IPv6 (0x86DD) but the IP header version field is not 6. This typically indicates packet corruption on the cluster control link, either due to hardware issues (faulty NIC, cable, or switch port), driver problems, or in rare cases, software bugs in cluster packet encapsulation. The cluster control link is used for inter-member communication including state replication, director-to-member coordination, and packet forwarding between cluster units.

Recommendation:

Investigate the cluster control link for hardware or connectivity issues. Check the physical cabling, switch ports, and network interface cards on all cluster members. Review interface statistics on the cluster control link interface for input errors, CRC errors, or other physical layer problems. If the issue persists, capture traffic on the cluster control link to examine the malformed packets. Consider testing with different cables or switch ports. If hardware checks are clean and the problem continues, collect troubleshooting data and contact Cisco TAC, as this may indicate a software defect in cluster packet handling or driver issues.

Syslogs:

None.

----------------------------------------------------------------

cluster-no-msgp

Cluster message descriptor pool exhausted on receive

The cluster unit exhausted its pool of message descriptors while attempting to process incoming cluster control messages from peer members. Message descriptors are internal resources used to parse and handle cluster state synchronization messages, including flow replication updates, NAT pool ownership changes, and other cluster logic updates. When the descriptor pool is depleted, incoming cluster messages cannot be processed and must be dropped. This typically occurs when the cluster is under sustained high load with rapid connection establishment rates, causing the unit to receive cluster synchronization messages faster than it can process and release descriptors. High-volume environments with features that generate frequent cluster updates—such as dynamic NAT with many concurrent translations, VPN with connection replication, or asymmetric traffic patterns requiring extensive director-to-owner messaging—are most susceptible. Recent software versions addressed descriptor leakage issues and inefficient deferred message processing that could contribute to pool exhaustion.

Recommendation:

Monitor the rate of this counter during peak traffic periods. Occasional drops may be transient and self-correcting as the system catches up with message processing. Sustained or rapidly increasing drops indicate the cluster is oversubscribed for the current traffic profile. Check cluster health with 'show cluster info' and verify all members are stable and processing traffic evenly. Review 'show asp drop' for other cluster-related drops that may indicate broader cluster stress. If drops persist, consider: reducing the connection rate or total connection count per cluster unit, increasing the cluster replication delay for short-lived flows to reduce synchronization overhead, disabling replication for specific traffic types that do not require high availability (such as HTTP), or adding cluster members to distribute load. Ensure the cluster control link has sufficient bandwidth and low latency. If the issue appeared after an upgrade or configuration change, review recent modifications to NAT, VPN, or traffic inspection policies. Upgrade to the latest recommended software version, as descriptor leakage and processing inefficiencies have been resolved in recent releases. Contact Cisco TAC if drops continue after tuning, providing 'show tech-support' and cluster statistics.

Syslogs:

None.

----------------------------------------------------------------

cluster-non-ip-pkt

Non-IP packet received on cluster control link

A packet was received on the cluster control link (CCL) interface with a Layer 3 protocol other than IPv4, IPv6, or ARP. The CCL is a dedicated interface used exclusively for cluster member communication, including health monitoring, state replication, and packet forwarding between cluster units. Only IPv4, IPv6, and ARP traffic is expected on this interface. This counter increments when the device receives frames with other Ethernet types (such as spanning tree BPDUs, LLDP, CDP, or other Layer 2 control protocols) on the CCL interface. This typically indicates that the CCL interface is connected to a switch port that is forwarding unwanted Layer 2 control traffic, or that the CCL is sharing a network segment with other devices or protocols.

Recommendation:

Verify that the cluster control link interface is connected to a dedicated network segment isolated from regular data traffic and other devices. Check the switch configuration for the CCL port: disable spanning tree (or configure it as an edge/portfast port), disable LLDP and CDP on the switch port, and ensure no VLAN tagging or trunking is configured unless explicitly required by your cluster design. If the CCL shares a switch with other devices, consider using a dedicated VLAN for cluster control traffic. Review the cluster control link configuration with 'show cluster info' and 'show interface' for the CCL interface. These drops are typically benign and do not affect cluster operation, but persistent high counts may indicate a misconfigured switch port or network design issue. If the cluster is functioning normally, no action is required.

Syslogs:

None.

----------------------------------------------------------------

cluster-non-owner-ignored

Multicast data packet dropped on non-owner cluster unit

A multicast data packet (destination 224.0.0.0/4) was received on an interface configured for Individual interface mode (L3 clustering) when the receiving unit was not the elected owner for that multicast flow. In Individual interface mode clustering, only the cluster master unit is permitted to process multicast data traffic; all other cluster members drop these packets to prevent duplicate forwarding. Control traffic such as reserved multicast addresses (224.0.0.0/24), Auto-RP, and ICMP multicast packets are still processed on all units. This counter does not apply to Spanned EtherChannel mode (L2 clustering) where multicast is handled differently.

Recommendation:

This counter is informational and indicates expected behavior in Individual interface mode clustering with multicast routing enabled. The multicast data packet is processed by the cluster master unit. No action is required unless you observe multicast forwarding failures, in which case verify that the cluster master is reachable and that multicast routing is properly configured. If the cluster is using Spanned EtherChannel mode (L2), this counter should not increment; if it does, verify the cluster interface-mode configuration is consistent across all members.

Syslogs:

None.

----------------------------------------------------------------

cluster-not-owner

Cluster Not Owner

A cluster member received a data packet that should be handled by a different member (the flow owner), but the owner identifier is invalid or does not correspond to any active cluster member. This occurs when the cluster attempts to redirect a packet to another member for processing, but cannot resolve the owner to a valid member ID. Common scenarios include: a cluster member's data interface is not yet ready (during join or rejoin operations) and attempts to redirect packets based on decoded owner information that is stale or invalid; cluster membership changes where a member has left or been removed but packets still reference it as the owner; or transient states during cluster topology updates where ownership information has not fully synchronized across all members.

Recommendation:

This counter typically increments during normal cluster operations when members join, leave, or restart. Brief increments during these events are expected and benign. Investigate if the counter increases continuously during stable cluster operation, which may indicate: persistent cluster membership instability (check 'show cluster info' for members flapping between join/leave states); data interface initialization problems on one or more members (verify all cluster data interfaces are up and operational); or cluster control link issues preventing proper ownership synchronization. Review cluster health with 'show cluster info status' and check for members stuck in 'Joining' or other non-stable states. If drops persist during stable operation, collect cluster debugs and contact Cisco TAC.

Syslogs:

None.

----------------------------------------------------------------

cluster-not-supported

Clustering not supported with BVI egress

Traffic was dropped because it was destined to exit through a Bridge Virtual Interface (BVI) on a device running in cluster mode. When routing determines that a packet should exit via a BVI, the system must resolve which specific physical member interface within the bridge group should carry the traffic. This resolution process—which involves looking up the next-hop MAC address in the adjacency table and then finding the corresponding member interface in the Layer 2 forwarding table—is not yet supported when clustering is enabled. This limitation applies specifically to BVI interfaces configured in routed mode (where the BVI participates in routing and forwards traffic between bridge groups or to routed interfaces). The drop occurs during the slow-path processing of new flows, before a connection is established.

Recommendation:

If you require BVI functionality in routed mode (where the BVI has a nameif and participates in inter-VLAN routing), you must disable clustering. Alternatively, reconfigure your network topology to avoid routing traffic through BVI interfaces—for example, by using standard routed interfaces instead of bridge groups for inter-VLAN routing. Note that BVIs used solely for management access within a single bridge group (transparent mode) do not trigger this limitation. If you see this counter incrementing, verify your interface configuration with 'show interface' and 'show nameif' to identify which BVI is involved, and review your routing table with 'show route' to understand why traffic is being routed to that BVI. This is a known architectural limitation, not a defect.

Syslogs:

None.

----------------------------------------------------------------

cluster-owner-update

Cluster Owner Update

A cluster unit received a data packet matching a stub flow (partial flow state used for forwarding) and was elected to become the full owner of that connection. The unit promoted the stub flow to a complete flow entry but dropped the triggering packet. This occurs during normal cluster operation when flow ownership changes—for example, when a connection's original owner leaves the cluster, or when dynamic NAT/PAT selects this unit as the new owner. The stub-to-full conversion requires the packet to be dropped; the connection remains active and subsequent packets (including retransmissions) will be processed normally by the newly promoted flow.

Recommendation:

This counter reflects normal cluster flow ownership transitions and does not indicate a problem. Small counts are expected during cluster membership changes, failover events, or when NAT pool ownership shifts. If this counter increments steadily during stable cluster operation with no topology changes, verify that cluster control link connectivity is healthy and that all units are running the same software version. No action is required for occasional increments.

Syslogs:

None.

----------------------------------------------------------------

cluster-peer-mcast-ignored

Multicast packet received from cluster peer on L3 cluster interface

A multicast data packet was received on an interface configured for Layer 3 clustering (individual interface mode) and was identified as originating from a peer cluster unit's corresponding interface. This occurs when a cluster unit forwards a multicast packet out to the Layer 3 subnet, and the packet is subsequently flooded back by the network to all interfaces on that subnet, including the interfaces of other cluster members. The receiving cluster unit recognizes the packet as one that was already processed by a peer unit and drops it to prevent duplicate processing and forwarding loops. This behavior is specific to Layer 3 clustering deployments where each cluster unit has its own IP address on shared subnets, and multicast traffic forwarding can result in packets being reflected back from the network infrastructure.

Recommendation:

This counter is informational and indicates normal, expected behavior in Layer 3 cluster environments with multicast traffic. The packet has already been forwarded by another cluster member and should be ignored to avoid duplicate delivery. No action is required. If this counter increments rapidly or you observe multicast forwarding issues, verify that PIM neighborship and multicast routing are correctly configured across all cluster units, and ensure that the cluster control link is stable. For troubleshooting multicast in clustering environments, use 'show mroute', 'show pim neighbor', and 'show asp cluster counter' to verify multicast state synchronization across cluster members.

Syslogs:

None.

----------------------------------------------------------------

cluster-queued-ccl-unknown

Queued cluster packet dropped due to invalid sender or director change

This counter increments when a packet that was queued for asynchronous director flow creation is dropped because cluster membership changed while the packet was waiting in the queue. Specifically, the packet was received over the cluster control link requesting director flow creation (typically for NAT flows), but when the queued packet was finally processed, either the sending cluster member became invalid (disabled, removed, or not found in the membership table) or this unit is no longer the correct director for the flow based on the current hash distribution. This occurs during cluster topology changes such as member joins, leaves, or role transitions that happen between the time a packet is queued and when it is processed from the work queue. The drop protects against stale cluster state by validating that both the sender member ID is still valid and that the local unit is still the computed director for the flow before creating the director flow entry.

Recommendation:

This drop is typically transient and occurs during normal cluster membership changes. The affected connection will be retried by the client and should succeed once cluster membership stabilizes. If this counter increments continuously, investigate cluster stability: check for frequent member joins/leaves, CCL link flapping, or members repeatedly transitioning between enabled and disabled states. Review cluster health with 'show cluster info' and 'show asp drop' to correlate with other cluster-related drops. Persistent occurrences may indicate underlying cluster control link issues, member health problems, or configuration mismatches causing repeated topology changes. For NAT flows specifically, verify that NAT configuration is consistent across all cluster members.

Syslogs:

None.

----------------------------------------------------------------

cluster-semi-scale-not-ready

Cluster semi-scalable flow owner not yet determined

This counter increments when a cluster member receives a packet for a semi-scalable flow during bulk synchronization, but the cluster has not yet elected a new owner for that flow. Semi-scalable flows separate control and data plane processing across cluster members. When the original flow owner leaves the cluster or becomes unavailable, the cluster must determine a new control director to own the flow. Until this election completes, packets arriving for the flow are dropped. This is a transient condition that occurs during cluster membership changes, such as when a unit joins, leaves, or fails, triggering bulk synchronization to redistribute flow ownership. The drop protects against forwarding packets to an invalid or unavailable owner while the cluster converges on the new topology.

Recommendation:

These drops are expected during cluster topology changes and should be temporary. Monitor for: (1) Sustained or high drop rates, which may indicate repeated cluster instability, frequent member failures, or slow bulk synchronization convergence. (2) Application-level retransmissions should recover the affected flows once the new owner is elected. (3) If drops persist after bulk synchronization completes (check 'show cluster info' for member status), investigate cluster control link health, inter-site connectivity in multi-site clusters, or resource exhaustion preventing timely owner election. (4) Review cluster event logs and syslog 785001 messages to identify which flows are being reassigned and why. If the counter increments continuously without cluster membership changes, contact Cisco TAC.

Syslogs:

785001 (flow ownership changes)

----------------------------------------------------------------

cluster-stub-to-full

Cluster stub flow promoted to full flow

A packet arrived at a cluster unit that was acting as the director for a stub flow, and the local unit has now become the owner of that connection. The stub flow (a lightweight placeholder used during cluster replication) was converted to a full flow to handle future packets. The triggering packet is dropped because the conversion process cannot immediately process it; the packet will be retransmitted by the sender and processed normally by the newly created full flow. This occurs during cluster ownership transitions, such as when a unit leaves the cluster, during NAT pool ownership changes, or when director election assigns ownership to the local unit.

Recommendation:

This is a normal, expected drop during cluster operation and does not indicate a problem. The dropped packets will be retransmitted by the sender (TCP) or application (UDP) and processed successfully by the full flow. If you observe a high rate of these drops, it may indicate frequent cluster membership changes or ownership transitions. Check cluster health with 'show cluster info' and review cluster topology stability. Ensure the cluster control link has sufficient bandwidth and low latency. For persistent issues with specific traffic types, verify that NAT pool configurations are stable across cluster members.

Syslogs:

None.

----------------------------------------------------------------

cluster-stub-uninterested

Cluster stub uninterested

A packet matched a cluster stub flow on a node that has no role in managing that flow. Stub flows are lightweight forwarding entries created on cluster nodes to redirect traffic to the connection owner. This drop occurs when a packet arrives at a forwarder node (a node that is neither the director, local director, nor backup for the flow) and the flow owner is invalid or has left the cluster. The forwarder has no authority to make ownership decisions and cannot determine where to send the packet, so it drops the traffic. This typically happens during cluster membership changes when a flow owner leaves the cluster but stub flows on forwarder nodes have not yet been cleaned up, or during timing windows where stub flows are created before ownership is fully established. It can also occur during VPN session redistribution in inter-site cluster deployments when stub flow state becomes inconsistent across sites.

Recommendation:

This drop is usually transient and self-correcting as cluster membership stabilizes and stale stub flows time out. If drops persist, verify cluster health with 'show cluster info' and check for nodes repeatedly joining and leaving. For VPN deployments, ensure all cluster nodes have consistent VPN configuration and that session redistribution completes successfully. If drops occur continuously during stable cluster operation, check for asymmetric routing that may be directing traffic to the wrong cluster node. In inter-site cluster deployments with VPN, temporary drops during node removal or addition are expected; monitor that traffic recovers after the cluster converges. If the issue persists beyond cluster membership changes, collect 'show asp drop' output, cluster debugs, and contact Cisco TAC.

Syslogs:

None.

----------------------------------------------------------------

cluster-tp-sender-myself

Cluster packet received with local unit's own ID as sender

A packet was received on the Cluster Control Link where the sender identifier matches this unit's own cluster member ID. This typically occurs when two independent clusters with overlapping member IDs are connected to the same network segment, causing cross-cluster traffic. Each cluster unit is assigned a unique numeric identifier (1-16) during cluster formation; when packets arrive claiming to originate from the local unit's own ID, they are dropped to prevent processing of invalid cluster control messages. Less commonly, this can indicate a network loop causing CCL packets to return to the sender, or a configuration error where two units were assigned the same ID during manual cluster setup.

Recommendation:

Verify that only one cluster is connected to the network segment carrying Cluster Control Link traffic. Check that all units in the cluster have unique member IDs using 'show cluster info' on each unit. If multiple independent clusters exist in the same environment, ensure they are on isolated network segments or VLANs. If the counter increments continuously, check for Layer 2 loops on the CCL interface. If the issue occurred after adding a new unit, verify the unit was properly reset to factory defaults before joining the cluster. Contact Cisco TAC if the counter increments without multiple clusters or obvious misconfigurations.

Syslogs:

None.

----------------------------------------------------------------

cluster-tp-version-incompatible

Cluster control message has incompatible transport protocol version

The device received a cluster control message over the Cluster Control Link (CCL) with a transport protocol version that does not match the local version. The CCL is used for inter-member communication including health monitoring, state replication, and coordination between cluster units. Each cluster member encodes control messages using an internal transport protocol version, and all members must use the same version to communicate successfully. This drop occurs when a cluster member receives a message encoded with a different transport protocol version than it expects, preventing the message from being processed. This typically happens when cluster members are running significantly different software releases that use incompatible internal messaging formats, or during a mixed-version upgrade scenario where members have not yet converged to the same protocol version.

Recommendation:

Verify that all cluster members are running the same software version using 'show cluster info'. Mixed software versions in a cluster are not supported for normal operation and can cause communication failures. If performing a cluster upgrade, ensure you follow the recommended hitless upgrade procedure where all members are upgraded in sequence and allowed to rejoin before traffic is restored. If all members show the same software version but this counter is incrementing, the cluster may be in an inconsistent state - consider removing and re-adding the affected member to the cluster. If the problem persists after ensuring version consistency, contact Cisco TAC as this may indicate a software defect or corruption in the cluster configuration.

Syslogs:

None.

----------------------------------------------------------------

cluster-ttl-expired

Cluster packet received with invalid TTL value

This counter increments when a cluster member receives a packet over the cluster control link (CCL) with an IP Time-To-Live (TTL) or IPv6 Hop Limit value that does not match any expected cluster packet type. In clustering deployments, the system uses specific TTL values as internal markers to identify different types of inter-member traffic: control plane messages, data plane forwarded packets, and flow lookup requests. When a packet arrives on the CCL interface with a TTL value outside the valid range for cluster operations, it is dropped to prevent processing of malformed or corrupted cluster traffic. This typically occurs only when cluster packets are corrupted in transit, when non-cluster traffic is mistakenly sent to the CCL interface, or during certain misconfigurations where external traffic reaches the dedicated cluster interface.

Recommendation:

This counter should remain at zero or very low in a healthy cluster. If this counter is incrementing, verify that the cluster control link interface is properly isolated and not receiving external traffic. Check physical cabling to ensure the CCL interface is connected only to other cluster members on a dedicated switch or VLAN. Review the cluster interface configuration on all members to confirm they are using the correct interface and IP subnet. If the counter increments during periods of high cluster traffic or network congestion, investigate potential packet corruption on the CCL network path—consider checking switch health, cable integrity, and interface error counters. Persistent increments may indicate a software issue; collect packet captures on the CCL interface and contact Cisco TAC with the output of 'show asp drop', 'show cluster info', and any CCL packet captures.

Syslogs:

None.

----------------------------------------------------------------

cluster-ttl-invalid

IPv6 hop limit out of range on cluster control link

An IPv6 packet received on the cluster control link (CCL) was dropped because its hop limit value exceeded the expected range for inter-cluster communication. The cluster control link uses specific hop limit values to distinguish between different types of cluster traffic: control plane messages, data plane forwarded packets, and internal lookup messages. When an IPv6 packet arrives with a hop limit outside the valid range for cluster operations, it indicates either a misconfiguration, an external packet incorrectly routed to the CCL interface, or corruption during transmission between cluster members. This counter only increments for IPv6 traffic; IPv4 cluster traffic uses TTL validation with a separate drop counter (cluster-ttl-expired).

Recommendation:

Verify that the cluster control link interface is dedicated to cluster traffic and not receiving external IPv6 packets. Check that no routing or forwarding rules are directing non-cluster traffic to the CCL interface. If the cluster is using IPv6 for the cluster control link, ensure all cluster members are running compatible software versions and that there are no intermediate devices (routers, switches) modifying the IPv6 hop limit between cluster members. Review the cluster control link configuration with 'show cluster info' and 'show interface' for the CCL interface. If drops persist and cluster stability is affected, collect a packet capture on the cluster control link to identify the source of packets with invalid hop limits, and contact Cisco TAC with the capture and output from 'show asp drop' and 'show cluster'.

Syslogs:

None.

----------------------------------------------------------------

cluster-vpn-fwdr-flow-reset

Cluster VPN forwarder flow reset

An encrypted IPsec packet (ESP or IKE over NAT-T) was received on a cluster node that had previously created a forwarding flow to redirect packets to another member, but the packet's cluster metadata indicates it was incorrectly sent back to this node. This occurs when cluster topology changes (such as a member leaving the cluster, flow ownership redistribution, or rebalancing) cause temporary inconsistencies in which node owns a particular VPN flow. The receiving node detects the mis-direction, drops the packet, and sends a notification to the original sender to delete the stale forwarding flow entry. This prevents packet loops and allows the cluster to converge on the correct flow ownership.

Recommendation:

This counter is informational and indicates normal cluster convergence behavior during topology changes. Small increments during cluster member joins, leaves, or load rebalancing are expected and do not indicate a problem. The affected VPN flows will recover automatically as the cluster updates flow ownership information. However, if this counter increments continuously or at a high rate during stable cluster operation, it may indicate a cluster control link issue, persistent flow ownership conflicts, or a software defect. In such cases, verify cluster control link connectivity and health, check for asymmetric routing of VPN traffic, and review cluster member status. Contact Cisco TAC if the counter grows rapidly without corresponding cluster topology changes.

Syslogs:

None.

----------------------------------------------------------------

cmd-invalid-encap

Invalid Cisco Metadata (CMD) Encapsulation

The firewall received a packet with Cisco Metadata (CMD) encapsulation containing an invalid header. CMD encapsulation is used to carry Security Group Tag (SGT) information inline with the packet for TrustSec policy enforcement. The firewall validates several header fields including the ethertype, version, length, option type, and SGT value. This counter increments when any of these validations fail. The most common cause is an invalid SGT value: valid SGTs range from 1 to 65533. SGT 0 is reserved to indicate an unknown security group, and SGT 65535 (0xFFFF in hexadecimal) is reserved as invalid and will always be dropped. This typically occurs when receiving traffic from upstream network devices (such as switches) that are configured for TrustSec inline tagging using the 'cts manual' command, but are sending malformed CMD headers or using reserved SGT values.

Recommendation:

1. Examine the dropped packet using 'capture asp-drop cmd-invalid-encap' to identify the specific SGT value and CMD header fields. Look for SGT values of 0 or 65535 (shown as 'ffff' in hexadecimal captures). 2. Verify the TrustSec configuration on directly connected devices that inject CMD headers. Ensure they are configured to use valid SGT values in the range 1-65533. 3. Check the SGT assignment policy on upstream devices (such as ISE or switches with 'cts manual' configuration) to ensure they are not assigning reserved SGT values. 4. If the upstream device is a Cisco switch, verify the 'cts role-based sgt-map' configuration and ensure proper SGT propagation. 5. This drop is expected and correct behavior when invalid SGT values are received - the firewall is protecting against malformed TrustSec metadata.

Syslogs:

None.

----------------------------------------------------------------

conn-disallow

Connection Disallowed by Policy

The device has temporarily blocked new connection establishment to protect audit trail integrity or service availability. This drop occurs when the system enters a connection-blocking state due to one of three conditions: (1) TCP syslog server is unreachable and the 'logging permit-hostdown' command is not configured, (2) the internal syslog message queue is full and cannot accept new audit events, or (3) the auto-update server timeout has expired without successful contact. The block applies to all new connection attempts across all interfaces (except management traffic, locally-originated traffic, and WebVPN sessions, which are exempted). Existing connections continue to forward traffic normally. This is a protective measure: when TCP-based syslog is configured, the device prioritizes maintaining a complete audit trail over accepting new sessions. If audit logging cannot be guaranteed, the default behavior is to deny new connections rather than allow unlogged activity.

Recommendation:

Check syslog 201008 to identify the specific blocking reason. If the cause is an unreachable TCP syslog server, verify network connectivity to the syslog destination and check the server's availability. To allow new connections even when the TCP syslog server is down (accepting the risk of lost audit logs), configure 'logging permit-hostdown'. If the cause is a full syslog queue, investigate what is generating excessive log volume or causing slow log delivery. If the cause is auto-update timeout, verify connectivity to the configured auto-update server or adjust the timeout value with 'auto-update timeout'. The block is automatically lifted when the underlying condition resolves: when the TCP syslog server reconnects, when the queue drains, or when the auto-update server responds. On ASA virtual (ASAv) with external database integration during boot, temporary connection blocks to the WebVPN port may occur until configuration completes; these are transient and self-resolve.

Syslogs:

201008

----------------------------------------------------------------

conn-limit

Connection limit reached

A new connection was denied because the configured connection limit was exceeded. This counter tracks drops due to system-wide or per-context connection limits, not class-map policy limits. In single-context mode, the system-wide connection limit (configured with 'set connection conn-limit') was reached. In multi-context mode, either the per-context limit (configured with 'limit-resource conns' in the context class) or the system-wide limit was exceeded. The limit applies to all connection types—TCP, UDP, SCTP, and ICMP. When this counter increments, syslog 201011 is generated showing the current connection count, the configured limit, and the source/destination addresses of the denied connection. In cluster deployments, the limit includes connections on all cluster members.

Recommendation:

Check syslog 201011 to identify which limit was exceeded and which hosts are being denied. Use 'show resource usage' (multi-context) or 'show blocks' and 'show conn count' (single-context) to verify current connection usage. If the traffic is legitimate, increase the connection limit using 'set connection conn-limit' (single-context) or 'limit-resource conns' (multi-context class configuration). If usage is below the configured limit but drops still occur, this may indicate a known accounting issue on multi-core platforms—check for available software updates. If a specific host is consuming excessive connections, investigate whether the host is under attack or misconfigured. In multi-context deployments, verify that both per-context and system-wide limits are appropriately sized for your traffic patterns.

Syslogs:

201011

----------------------------------------------------------------

connection-lock

Connection lock acquisition failed

A packet was queued for asynchronous processing (typically returning from an inspection engine such as Snort, or being injected by the system), but by the time the packet was ready to be processed, the connection it belonged to had been torn down and its lock released. This is a race condition between packet processing and connection teardown. Common scenarios include: (1) Packets returning from deep packet inspection (Snort/IPS) after the connection has been closed or reset. (2) System-generated packets (such as ICMP error messages) that are dispatched asynchronously but arrive after the associated flow has been terminated. (3) Administrative actions such as 'clear conn' executed while packets are queued for processing. (4) High-rate traffic scenarios where multiple packets for the same short-lived flow are queued, and the flow terminates before all queued packets can be processed.

Recommendation:

This counter typically indicates normal race conditions in high-throughput or short-lived connection scenarios and is usually benign. However, investigate further if: (1) The counter is incrementing rapidly and correlates with user-reported connectivity issues. (2) You recently executed 'clear conn' commands or made configuration changes that force connection teardowns. (3) The drops correlate with specific traffic patterns, such as bursts of ICMP traffic with TTL expiration, or connections with aggressive timeout values. Check 'show asp drop' for the flow-expired counter as well, which often increments alongside this counter. If drops are impacting production traffic, consider: (1) Reviewing inspection policies that may be causing excessive delays in packet processing. (2) Checking for defects related to specific traffic patterns (such as CSCwr43586 for ICMP TTL-exceeded scenarios with decrement-ttl policy). (3) Avoiding frequent use of 'clear conn' commands on active systems. If the counter grows continuously without corresponding user impact, it is likely normal system behavior and can be ignored.

Syslogs:

None directly associated. However, related syslogs may appear depending on the traffic type (e.g., IPS drop messages 420002, or connection teardown messages 302013/302014).

----------------------------------------------------------------

connection-q-expired

Flow work queue unavailable during packet reinjection

This counter increments when the appliance attempts to reinject a packet back into the data path after control-plane processing, but the internal work queue needed to process the packet is unavailable. The flow still exists at the time of reinjection (the flow handle is valid), but the work queue required to continue processing cannot be obtained. This occurs in specific scenarios where packets are temporarily diverted for processing and then returned to the data path: DNS inspection with Cisco Umbrella integration (when DNS responses are received from Umbrella and need to be reinjected toward the original client flow), DNScrypt decryption (when encrypted DNS responses are decrypted and reinjected), and ARP resolution (when packets queued pending ARP resolution are reinjected after the MAC address is learned). The most common trigger is Umbrella DNS inspection, where responses from the Umbrella resolver must be modified and reinjected to the downstream client flow. If that flow has timed out or is being torn down by another thread during the reinjection window, the work queue becomes unavailable.

Recommendation:

This drop typically indicates a timing issue where a flow expired or was torn down between the time a packet was sent for processing and when it was ready to be reinjected. For Umbrella DNS: verify that the 'umbrella-timeout' value in the DNS inspection policy provides sufficient time for Umbrella to respond before the original DNS flow times out (default is 5 seconds). If you see frequent drops, consider increasing the timeout. For DNScrypt: ensure that encrypted DNS flows have adequate idle timeouts to accommodate decryption latency. For ARP-related drops: verify that ARP timeouts are appropriate for your network. If drops are infrequent and sporadic, they are typically benign—representing normal race conditions during flow cleanup. If drops are frequent or correlate with DNS resolution failures, capture 'show asp drop' output during the issue, enable DNS inspection debugging, and contact Cisco TAC with packet captures showing the DNS transaction timing.

Syslogs:

None

----------------------------------------------------------------

cp-event-queue-error

Control plane event queue full

The data plane attempted to send an event to the control plane for processing, but the control plane event queue was full and rejected the request. These queues bridge the data plane and control plane in multi-core systems, carrying various event types including packets requiring deep inspection, syslog messages, SNMP traps, routing updates, high-availability synchronization messages, and ARP/adjacency notifications. When a queue reaches its maximum depth, new events are tail-dropped to prevent memory exhaustion. Common triggers include bursts of SNMP trap generation during resource limit conditions (connection limits, NAT pool exhaustion), sustained high traffic requiring control plane processing, or control plane processing delays that prevent timely queue draining. The specific module that attempted the enqueue may increment its own drop counter in addition to this general counter.

Recommendation:

Check 'show asp event dp-cp' to identify which specific event queue is full and review the enqueue failure counts per event type. Look for syslog 447001 messages that identify the queue name and depth. If SNMP-related queues show high enqueue failures, verify whether SNMP traps are configured and consider disabling unnecessary traps during resource exhaustion events. For punt-related queue overflows, investigate what traffic is being punted to the control plane and whether inspection policies or classification rules can be optimized. If the condition is transient and connections are not impacted, no action may be needed. If the counter increments continuously or connections fail, collect 'show asp drop', 'show asp event dp-cp', and 'show tech-support' and contact Cisco TAC for analysis of control plane processing bottlenecks.

Syslogs:

447001

----------------------------------------------------------------

cp-syslog-event-queue-error

Control plane syslog event queue full

This counter increments when the device cannot queue a syslog message from the datapath to the control plane because the internal event queue has reached its maximum depth. This condition occurs only on multi-core platforms where packet processing (datapath) and logging (control plane) run on separate CPU cores. The queue handles syslog messages destined for non-UDP targets: console, buffered logging, ASDM, email alerts, and SNMP traps. When the queue fills, the datapath discards the syslog message to avoid blocking packet processing. UDP syslog servers are not affected because those messages are sent directly from the datapath without queuing to the control plane. Common triggers include high logging levels (informational or debugging), verbose access-list logging, slow control plane processing due to CPU saturation, or a large number of non-UDP logging destinations. The counter reflects lost syslog messages, not dropped traffic.

Recommendation:

Check for syslog %ASA-4-447001, which reports the specific queue that filled and its depth. Use 'show asp event dp-cp' to monitor current queue lengths; the syslog event queue should normally be near zero. If this counter is climbing, reduce logging verbosity by raising the logging level from informational (6) or debugging (7) to warnings (4) or higher. Disable or reduce access-list logging if configured. Verify control plane CPU usage with 'show cpu usage'; sustained high CPU prevents timely syslog processing. Consider switching from console, buffered, or ASDM logging to UDP syslog servers, which bypass this queue entirely. If logging to multiple non-UDP destinations, reduce the number of targets. This condition is typically self-correcting once the logging burst subsides, but persistent increments indicate the logging configuration exceeds the platform's control plane capacity. Contact TAC if the counter grows continuously despite reducing logging levels.

Syslogs:

%ASA-4-447001

----------------------------------------------------------------

ctm-error

Crypto operation failed

The device attempted to encrypt or decrypt a packet using hardware or software cryptographic acceleration, but the operation failed. This counter increments when the crypto subsystem returns an error during IPsec VPN tunnel processing (encryption, decryption, or authentication) or SSL/TLS proxy operations (record encryption or decryption). Failures can occur due to hardware accelerator errors, invalid cryptographic parameters (such as corrupted keys, unsupported algorithm combinations, or incorrect padding), memory allocation failures during crypto operations, or internal state corruption in the crypto session. On platforms with dedicated crypto hardware (Nitrox, QAT, or similar accelerators), this may indicate a hardware fault or resource exhaustion. On virtual platforms or when hardware offload is unavailable, it reflects software crypto library errors.

Recommendation:

Enable syslog message 402123 to identify whether the failure is hardware or software related and to see the specific error code. Check 'show ipsec stats' for the global IPsec error counter; if incrementing, use 'show ipsec sa detail' to identify which tunnel is affected. For SSL/TLS proxy drops, correlate with SSL decryption policy and check for certificate or cipher suite mismatches. If the counter increments steadily or in bursts, check for crypto hardware health issues on physical platforms. On ASA 5500-X series or Firepower 4100/9300, hardware crypto failures may require RMA. If drops occur during IPsec rekey operations, this may indicate a resource leak (see CSCwc60037); reloading the device temporarily clears the condition, but a software upgrade to a fixed release is required for permanent resolution. Occasional increments during tunnel teardown or session closure are typically benign. Persistent or high-rate increments indicate a configuration issue, hardware fault, or software defect requiring TAC assistance.

Syslogs:

402123, 402124

----------------------------------------------------------------

cxsc-bad-handle-received

Packet returned from ASA CX module with mismatched flow identifier

The firewall received a packet back from the ASA CX (CXSC) inspection module, but the flow identifier in the packet header does not match the identifier previously established for this connection. This indicates the CX module has lost synchronization with the firewall's flow state, typically due to a module restart, internal error, or resource exhaustion on the module. When this mismatch is detected, both the packet and the entire flow are dropped to prevent processing packets with inconsistent security context. This counter only increments on ASA 5500-X platforms with an ASA CX module installed and configured for traffic inspection (fail-close or fail-open with authentication proxy). The ASA CX module is a deprecated product that provided next-generation firewall services including application visibility and control.

Recommendation:

Check the health and logs of the ASA CX module using 'show module' and 'session cxsc' commands. Look for module reloads, resource exhaustion, or error messages on the CX module itself. If the CX module is restarting frequently, investigate the root cause (software bugs, resource limits, hardware issues). Review the CX module configuration and ensure it has adequate resources for the traffic load. If the ASA CX module is no longer needed, consider migrating to Firepower Threat Defense (FTD) or removing the CX inspection policy. Note that ASA CX reached end-of-life and is no longer supported; Cisco recommends migration to current next-generation firewall solutions. A related syslog message may appear showing the affected flow details.

Syslogs:

Related syslog: The firewall may generate a message indicating invalid packet injection from the module, showing the protocol and IP addresses of the affected flow.

----------------------------------------------------------------

cxsc-bad-tlv-received

CXSC Module Returned Packet with Malformed TLV

The firewall dropped a packet that was returned from the deprecated CXSC (Context Security) module because the packet contained a malformed or invalid Type-Length-Value (TLV) structure in the module's control header. The CXSC module was a hardware add-on for ASA 5500-X platforms that provided identity-based access control and authentication proxy services. When traffic is diverted to the CXSC module for inspection, the module returns packets with metadata encoded in TLV format. This counter increments when the firewall cannot parse these TLVs due to incorrect type codes, invalid lengths, or corrupted data. This typically indicates a software compatibility issue between the ASA and CXSC module versions, or corruption in the inter-module communication channel.

Recommendation:

The CXSC module reached end-of-support and is no longer available or supported on current ASA platforms. If you see this counter incrementing, verify that both the ASA and CXSC module are running compatible software versions by checking the release notes. If the problem persists, the CXSC module may be experiencing hardware or software failure. Consider migrating to a supported next-generation firewall solution such as Firepower Threat Defense (FTD) with integrated threat inspection capabilities. If you must continue using CXSC temporarily, try reloading the module with 'sw-module module cxsc reload'. Contact Cisco TAC if the issue continues, as this may indicate inter-module communication problems requiring hardware replacement or configuration changes.

Syslogs:

None directly associated with this drop. Check for CXSC module health and data plane status messages.

----------------------------------------------------------------

cxsc-fail

CX Module Context Missing for Connection

This counter increments when a packet arrives for a connection that was previously configured for CX (Context-Aware Security) module inspection, but the CX module context is no longer available for that connection. This typically occurs during configuration changes to service policies that redirect traffic to the CX module, when the CX module is being reloaded or removed, or when the module becomes unavailable and its associated connection state is cleaned up. The packet is dropped because the system cannot forward it to the CX module without the required inspection context.

Recommendation:

This drop is expected during administrative changes to CX module configuration or service policies. If the counter increments during normal operation without configuration changes, verify the CX module status using 'show module' and check for CX module reload events in the logs. Review the service policy configuration with 'show service-policy' to confirm the cxsc action is properly configured. If the CX module is intentionally being removed, existing connections will be dropped until they are re-established. For unexpected drops, check whether the fail-open or fail-close mode is appropriate for your environment, and verify the CX module is operational. If drops persist without configuration changes or module issues, contact Cisco TAC.

Syslogs:

429004, 429005, 429006

----------------------------------------------------------------

cxsc-fail-close

Content Security module unavailable with fail-close policy

Traffic was redirected to the ASA Content Security (CX) module for inspection via a service policy, but the module is currently down or unresponsive, and the service policy is configured with fail-close behavior. In fail-close mode, the security appliance prioritizes security over availability—if the inspection module cannot process traffic, packets are dropped rather than bypassing inspection. This counter increments for each packet dropped due to this condition. The CX module may be down due to hardware failure, software crash, configuration changes, or administrative shutdown. This feature applies to ASA platforms with CX service modules and is typically seen when the module status shows anything other than 'Up' while traffic continues to match the redirection policy.

Recommendation:

First, verify the CX module status and identify why it is unavailable. Check the module state and application status to determine if the module has failed, is recovering, or was administratively disabled. If the module failure is temporary and traffic availability is critical, consider temporarily changing the service policy to fail-open mode to permit traffic to bypass inspection until the module is restored—however, understand that this reduces security posture. If the module cannot be recovered quickly, either remove the service policy redirection to stop sending traffic to the unavailable module, or apply access control lists to explicitly permit or deny the affected traffic. For permanent module failures, plan to replace the hardware or migrate to alternative inspection solutions. If the module appears operational but this counter continues to increment, contact Cisco TAC as there may be a communication issue between the security appliance and the module.

Syslogs:

429001

----------------------------------------------------------------

cxsc-ha-request

CXSC HA replication drop

This counter increments when the security appliance receives a high-availability replication packet from the ASA CX (Context-Aware Security) module but cannot process it. The CXSC module is a legacy application inspection module that ran on ASA 5500-X series platforms and required its own HA state synchronization separate from the main ASA failover mechanism. Drops occur when the ASA and CXSC module are temporarily out of sync regarding HA state—for example, immediately after a failover event when the CXSC module has not yet learned the new active/standby roles. Drops can also occur if the replication message exceeds size limits, if memory is exhausted, or if the HA stateful link is down. This counter is only relevant on ASA 5500-X platforms with CXSC modules installed; it does not apply to modern FTD deployments or ASA platforms without CXSC.

Recommendation:

Occasional increments during failover transitions are normal and expected—the CXSC module will resynchronize within seconds. If the counter increases constantly during stable operation, verify that both ASA units show matching HA states (active/standby) and that the CXSC module status is consistent on both peers using 'show module'. Check that the HA stateful link is operational. Note that CXSC modules reached end-of-life and are no longer supported; if you encounter persistent issues, consider migrating to a modern platform. If the CXSC module is not intentionally in use, uninstall it to prevent unnecessary replication attempts. Contact Cisco TAC if the counter grows continuously and impacts service availability.

Syslogs:

None.

----------------------------------------------------------------

cxsc-invalid-encap

Invalid CX module encapsulation header

The security appliance received a malformed high-availability synchronization message from the ASA CX (Context-Aware Security) module and dropped it. This occurs when the message header contains an invalid IP version field, a length mismatch between the declared and actual packet size, or an unrecognized message type. The CX module was a deprecated hardware add-on for ASA 5500-X platforms that provided next-generation firewall capabilities. This counter tracks internal communication errors between the ASA data plane and the CX module during high-availability state synchronization, not end-user traffic drops.

Recommendation:

This counter should remain at zero during normal operation. If incrementing, verify the CX module software version is compatible with the ASA version and check for hardware issues with the module itself using 'show module' and 'show module details'. Because the ASA CX module reached end-of-life and is no longer supported in current ASA releases, persistent increments of this counter on modern deployments may indicate residual configuration or a platform migration issue. If the CX module is no longer in use, remove any CX-related service policies. Contact Cisco TAC if the counter increments on platforms without a CX module installed, as this may indicate a software defect.

Syslogs:

None

----------------------------------------------------------------

cxsc-malformed-packet

Content Security Module Returned Malformed Packet

The firewall dropped a packet because it received a malformed response from the ASA CX (Context-Aware Security) content security module. This counter increments when packets returning from the CX module contain corrupted or invalid protocol headers that fail integrity validation. The CX module communicates with the ASA data plane over a dedicated backplane channel; packets are sent to the module for advanced inspection and returned for forwarding. This drop occurs when the returned packet header contains invalid IP version fields, corrupted action flags, or inconsistent length and offset values. Common triggers include CX module software issues, backplane communication errors, or memory corruption on the module. This drop typically indicates a problem with the CX module itself rather than the original traffic.

Recommendation:

Check the health and status of the ASA CX module using 'show module' and 'show service-policy'. Review CX module logs and system messages for errors or warnings about module communication failures. If the counter is incrementing steadily, the CX module may be experiencing software instability or hardware issues. Verify the CX module software version is compatible with the ASA version. If the problem persists, consider temporarily configuring the service policy to 'fail-open' mode to allow traffic to bypass the module while troubleshooting, or reload the CX module. Collect 'show tech-support' output from both the ASA and CX module before contacting Cisco TAC if the issue continues.

Syslogs:

None

----------------------------------------------------------------

cxsc-request

CXSC Module Requested Drop

The packet was dropped because the ASA CX (Context-Aware Security) module inspected the traffic and determined it should be blocked based on the configured security policy. This occurs when traffic is redirected to the CX module via a service policy with the 'cxsc' action, and the CX module's inspection engine (which provides next-generation firewall capabilities including application visibility, identity-based policies, and advanced threat protection) identifies the traffic as violating policy. Common reasons include application blocking rules, URL category filtering, malware detection, or identity-based access denials. The CX module returns an explicit drop action to the ASA data plane, which increments this counter and blocks the packet.

Recommendation:

This is expected behavior when CX policies are actively blocking traffic. Review syslog message 429002, which identifies the specific connection that was dropped (source/destination IP and port). To investigate further: (1) Use 'show service-policy cxsc' to view CX redirection statistics and confirm the module is operational. (2) Check the CX module's own logs and dashboards to identify which security policy triggered the block (application control, URL filtering, malware detection, etc.). (3) If the block is unintended, adjust the CX security policy to permit the legitimate traffic. (4) Verify the CX module status with 'show module' to ensure it is functioning properly. Note: This counter only appears on ASA platforms with the legacy CX module installed and configured; it does not apply to modern Firepower Threat Defense (FTD) deployments.

Syslogs:

429002

----------------------------------------------------------------

cxsc-rx-monitor-only

CX module returned packet in monitor-only mode

The security appliance received a packet back from the CX (Content Security) module for a connection that is configured in monitor-only mode. In monitor-only mode, the CX module should passively inspect copies of traffic for logging and visibility purposes only, without returning packets to the data path. This counter indicates the CX module incorrectly attempted to return a packet that should have been inspected and discarded. This typically occurs when there is a configuration mismatch between the ASA and the CX module, or when the CX module software is experiencing internal errors. The affected traffic flow is configured with a service policy using 'cxsc fail-open monitor-only' or 'cxsc fail-close monitor-only'.

Recommendation:

Verify the CX module is operational using 'show module' and check for data channel communication errors with 'show asp event dp-cp cxsc'. Review the service policy configuration with 'show service-policy' to confirm monitor-only mode is correctly applied. If the counter increments frequently, check the CX module logs for errors and consider reloading the module using 'sw-module module cxsc reload'. If the issue persists after module reload, contact Cisco TAC with the output of 'show tech-support' and 'show module cxsc details' as this may indicate a software defect in the CX module.

Syslogs:

323006 (CX module data channel communication failure)

----------------------------------------------------------------

daq-retry

Packet queued for SSL/TLS decryption retry

This counter increments when the inspection engine requests that a packet be queued for retry during SSL/TLS decryption processing. This occurs when the decryption subsystem needs additional processing time before the packet can be sent to the inspection engine, typically during certificate visibility operations or when establishing SSL/TLS session context. The packet is placed in a retry queue and will be reprocessed after the required decryption state is available. This is part of normal SSL/TLS inspection operation on FTD platforms and does not indicate packet loss—the packet is held temporarily and will be processed once decryption prerequisites are met.

Recommendation:

This counter incrementing is expected behavior during SSL/TLS inspection and does not require action. However, if this counter grows rapidly or continuously, verify that the PDTS communication channel between the firewall engine and inspection engine is healthy by checking 'show asp inspect-dp snort counters' for queue full conditions or transmission errors. On FTD 7.0 through 7.8, if you observe the 'show daq counters' command showing increasing WRITE_FAILED counters alongside high daq-retry counts, this may indicate PDTS queue saturation (see CSCwm40721). In such cases, review SSL/TLS inspection policy scope to reduce inspection load, or contact Cisco TAC if the device stops processing traffic.

Syslogs:

None.

----------------------------------------------------------------

defragmentation

Dropped by IP defragmentation preprocessor

The packet was dropped by the IP defragmentation preprocessor in the Network Analysis Policy. This preprocessor reassembles fragmented IP packets and enforces fragment handling policies. Drops occur when the preprocessor detects fragment anomalies, policy violations, or malformed fragment sequences. Common triggers include: fragments that would reassemble to an invalid total size, overlapping fragment offsets, fragments with inconsistent headers, or fragments that violate the configured defragmentation policy (Linux, BSD, Windows, etc.). The preprocessor may also drop fragments when zone assignment fails, particularly for tunneled traffic such as GRE. This counter indicates the preprocessor actively blocked the packet rather than silently passing it.

Recommendation:

Enable packet tracer or capture with detailed tracing to see the specific preprocessor rule or condition that triggered the drop. Review the Network Analysis Policy applied to the traffic and examine the IP Defragmentation settings, including the target-based policy (which OS fragmentation behavior to emulate) and any custom fragment timeout or memory limits. Check for legitimate fragmented traffic patterns that may be triggering false positives. If drops occur on tunneled traffic (GRE, IPsec), verify that zone assignment is correct and consider using a Prefilter Policy fastpath rule as a workaround. For persistent issues with legitimate traffic, adjust the defragmentation policy settings or consult TAC with packet captures showing the fragment sequence.

Syslogs:

None.

----------------------------------------------------------------

df-bit-set

Egress fragmentation needed, DF bit is set

This counter increments when a packet needs to be fragmented to fit the egress interface MTU, but the IP header Don't Fragment (DF) bit is set to 1, which prohibits fragmentation. The device drops the packet and sends an ICMP Type 3 Code 4 (Destination Unreachable - Fragmentation Needed) message back to the source, indicating the maximum MTU that can be accommodated. This is the expected behavior for Path MTU Discovery (PMTUD), allowing the source to adjust its packet size. Common scenarios include VPN tunnels where IPsec or SSL VPN encapsulation overhead reduces the effective MTU, packets traversing interfaces with mismatched MTU settings, or traffic from hosts using standard 1500-byte Ethernet frames when the egress path requires a smaller MTU. In versions prior to 9.14.3, this condition could result in silent drops without incrementing counters; ensure you are running 9.14.3 or later for accurate accounting.

Recommendation:

This drop is typically benign and part of normal PMTUD operation. Verify that ICMP Type 3 Code 4 messages are not being blocked by ACLs or upstream firewalls, as blocking these messages prevents PMTUD from functioning and causes persistent connectivity issues. Check the MTU configuration on the egress interface using 'show interface' and compare it to the size of dropped packets. For VPN scenarios, review tunnel MTU settings and consider adjusting the 'crypto ipsec df-bit' command (set-df, copy-df, or clear-df) to match your network requirements. If drops are excessive, investigate whether the sending hosts are performing PMTUD correctly or if they need TCP MSS adjustment. Use 'show asp drop' to monitor the counter rate; occasional drops are normal, but sustained high rates may indicate MTU misconfiguration or PMTUD failure. For clustered deployments, note that cluster control link traffic bypasses DF bit checking to maintain transparent operation.

Syslogs:

None

----------------------------------------------------------------

dispatch-block-alloc

Core-local packet buffer allocation failure

The appliance dropped a received packet because it could not allocate a core-local packet buffer on the CPU core processing the packet. Modern network drivers use a two-tier buffer architecture: the driver receives packets into driver-owned buffers, then the system allocates a lightweight core-local header structure to track the packet through the data path. This drop occurs when a specific CPU core has exhausted its allocation of these header structures. This is most commonly seen on virtual platforms (ASAv, FTDv) where control plane processes share CPU cores with packet processing, on systems with unbalanced traffic distribution across cores, or during sustained high traffic loads. The system includes a background rebalancing mechanism that redistributes unused buffers from idle cores to busy cores, but this drop can occur if rebalancing cannot keep pace with demand or if one core is persistently overloaded.

Recommendation:

Use 'show blocks core' to identify which CPU core(s) are experiencing allocation failures—look for cores where ALLOC equals LIMIT and FAILED is incrementing. If one or two cores show failures while others have low utilization, this indicates a load distribution problem. On virtual platforms, verify that control plane processes are not pinned to the same cores handling high packet rates. If using 'asp load-balance per-packet', verify the feature is functioning correctly—some software versions have had load balancing defects that cause all traffic to concentrate on a single core. For sustained failures across multiple cores during high traffic, the system may be undersized for the traffic volume. If failures are transient and self-correcting, the rebalancing mechanism is working but may be experiencing temporary delays. Contact Cisco TAC if failures persist, especially if concentrated on specific cores or if accompanied by significant packet loss.

Syslogs:

None

----------------------------------------------------------------

dispatch-decode-err

Dispatch Decode Error

The device could not decode the Layer 2 frame headers of a packet during load-balancing hash computation. This occurs when the packet dispatch module encounters an unrecognized or malformed frame encapsulation that prevents it from locating the Layer 3 header and computing a flow hash. Common triggers include: unsupported or corrupted Ethernet encapsulation types; malformed 802.1Q VLAN tags (including Q-in-Q or triple VLAN configurations); MPLS label stacks that exceed the maximum supported depth or lack a proper end-of-stack marker; improperly formatted Security Group Tag (SGT) ECMD headers; Cisco FabricPath header issues; or ERSPAN/GRE tunnel packets with invalid encapsulation. This drop typically indicates either a misconfiguration in VLAN tagging, MPLS label stacking, or tunnel encapsulation, or the presence of corrupted frames on the network. The counter increments during both normal packet transmission and when packets are reinjected into the data path after inspection or processing.

Recommendation:

Capture dropped packets using 'capture asp-drop dispatch-decode-err' to examine the frame structure. Verify that VLAN configurations match on both ends of the link, especially for Q-in-Q or stacked VLAN scenarios. If MPLS is in use, confirm that label stacks do not exceed platform limits and that the bottom-of-stack bit is set correctly. For environments using Security Group Tagging (SGT), verify ECMD header formatting. If ERSPAN or GRE tunnels are configured, check that tunnel encapsulation is properly formed and that any platform-specific requirements for tunnel traffic are met. Review interface configurations for any non-standard encapsulation settings. If drops persist with valid configurations, the issue may indicate hardware problems, driver issues, or upstream devices sending malformed frames—contact Cisco TAC with packet captures for further analysis.

Syslogs:

None

----------------------------------------------------------------

dispatch-queue-limit

Dispatch queue limit reached

The packet dispatcher uses 32,768 load-balancing queues to distribute incoming packets across CPU cores for parallel processing. Each queue can hold up to 1,000 packets. When a packet is hashed to a queue that is already at this limit, the packet is tail-dropped and this counter increments. This typically occurs during sustained traffic bursts where packets hash unevenly across queues, causing some queues to fill while others remain empty. Common scenarios include high connection-rate events (such as failover synchronization or bulk connection replication), elephant flows in multi-instance deployments, VPN traffic spikes, or traffic patterns with poor hash distribution (such as many connections with identical 5-tuple characteristics). On Firepower platforms, this drop is most often seen on standby units processing failover logical updates over the internal data interface, or during periods of extreme CPU load where packet processing cannot keep pace with arrival rates.

Recommendation:

Occasional drops are normal during traffic spikes and do not indicate a problem. Investigate if drops are sustained or growing rapidly. Check CPU utilization with 'show cpu usage' to determine if cores are saturated. Use 'show asp dispatch' to identify which queues are congested and whether specific traffic types are affected. For failover-related drops on standby units, verify that failover link bandwidth and latency are adequate. If drops correlate with specific traffic patterns (such as VPN sessions or inspection-heavy flows), consider whether traffic distribution can be improved or whether the platform is undersized for the traffic load. In multi-instance mode, verify that flow offload is enabled where supported. If drops persist under normal load conditions, collect 'show tech-support' and contact Cisco TAC, as this may indicate a software issue with queue management or hash distribution.

Syslogs:

None

----------------------------------------------------------------

dns-guard-id-not-matched

DNS Response Transaction ID Not Matched

This counter increments when the appliance receives a DNS response whose transaction ID (the 16-bit identification field in the DNS header) does not match any DNS query that previously traversed the same connection. The appliance tracks outbound DNS queries and their transaction IDs when DNS inspection is configured with one or more of the following security features: the global 'dns-guard' command, the 'id-randomization' parameter in a DNS inspection policy-map, or the 'id-mismatch' rate-limiting parameter. When a DNS response arrives, the appliance looks up the transaction ID in its per-flow tracking table; if no matching query is found, the response is dropped and this counter increments. This protection defends against DNS cache poisoning attacks, where an attacker floods forged responses hoping one will arrive before the legitimate server reply. Legitimate causes include: responses arriving after the query has timed out and been removed from the tracking table, duplicate or retransmitted responses after the first response already consumed the tracked query, responses to queries that were sent before DNS inspection was enabled on the flow, or in rare cases, a race condition where a query and its response cross in a very short time window (fixed in recent releases via CSCwj35701).

Recommendation:

If this counter increments occasionally, no action is required—it may reflect normal timeout behavior or duplicate responses. If the counter increments at a high rate, investigate whether: (1) DNS servers are sending duplicate responses or retransmitting excessively, (2) an attacker is attempting DNS cache poisoning (correlate with syslog 410002 if 'id-mismatch' logging is configured), or (3) clients are reusing the same 5-tuple (source IP, source port, destination IP, destination port, protocol) for rapid successive queries, which can trigger a known timing issue in older software versions. To reduce false positives, ensure DNS query timeout values align with your DNS server response times. If legitimate traffic is being dropped due to retransmissions or the timing race condition, consider disabling DNS Guard by configuring 'no dns-guard' under the DNS inspection policy-map (on FTD, use FlexConfig with 'no dns-guar' to avoid FMC validation errors). If syslog 410002 appears frequently, review the 'id-mismatch' threshold settings and verify whether the traffic pattern is malicious or benign.

Syslogs:

410002 (severity 2): Logged when the rate of DNS ID mismatches exceeds the threshold configured by the 'id-mismatch' parameter in the DNS inspection policy-map. This syslog is rate-limited and indicates potential DNS cache poisoning activity.

----------------------------------------------------------------

dns-guard-out-of-app-id

DNS Guard Out of Transaction ID Tracker

This counter increments when DNS Guard inspection cannot allocate an internal tracking structure to monitor a DNS query's transaction identifier. DNS Guard enforces that each DNS response matches a previously seen query by tracking the DNS transaction ID field. When a DNS query arrives, the system allocates a small data structure to store the transaction ID and associate it with the flow. If this allocation fails—typically due to memory exhaustion or resource limits—the query is dropped and this counter increments. The same mechanism is used by ICMP echo inspection to track sequence numbers. This drop occurs during query processing, before the query is forwarded to the DNS server.

Recommendation:

Check system memory usage with 'show memory' and 'show blocks'. If memory is critically low, investigate what is consuming memory (connections, inspections, VPN sessions, logging buffers). Review the rate of DNS queries per second; extremely high query rates can exhaust the per-flow tracking pool. If DNS Guard is not required for your security policy, consider disabling it with 'no dns-guard' in the DNS inspection policy-map (note: DNS Guard is enabled by default even without explicit DNS inspection configuration). On FTD, use FlexConfig to apply 'no dns-guard' under 'policy-map type inspect dns preset_dns_map parameters'. If the issue persists under normal memory conditions, contact Cisco TAC—this may indicate a resource leak or misconfiguration. Note that defect CSCwj35701 addressed a related issue where DNS Guard prematurely closed connections under high query rates, which could indirectly contribute to tracking structure exhaustion.

Syslogs:

None

----------------------------------------------------------------

dst-l2_lookup-fail

Destination MAC Address Not Found in Layer 2 Table

This counter increments when the device performs a Layer 2 destination MAC address lookup and cannot find a matching entry in the MAC address table. This occurs in transparent firewall mode, when using Bridge Virtual Interfaces (BVI) in routed mode, or during bridge group operations. When the lookup fails, the device sends a discovery request to the control plane to learn the destination MAC location via ARP or neighbor discovery, and drops the packet. Depending on configuration, certain non-IP traffic may be flooded to all bridge group members instead of dropped. This counter typically increments during initial network startup, after MAC table entries age out, following a 'clear mac-address-table' command, or when hosts first communicate through the device.

Recommendation:

This is normal behavior during MAC address learning. The counter will increment when the device has not yet learned where a destination MAC address is located. Check 'show mac-address-table' to verify that MAC addresses are being learned correctly on the appropriate interfaces. If the counter increments continuously for the same destination, verify that the destination host is reachable and responding to ARP requests. In transparent mode, verify that 'mac-learn disable' is not configured on interfaces where learning is needed. If using BVI interfaces, ensure bridge group membership is configured correctly. High sustained rates may indicate a MAC address table capacity issue, excessive aging timeout (check 'mac-address-table aging-time'), or a host that is not responding to discovery attempts. For troubleshooting, use 'packet-tracer' to simulate traffic and observe the Layer 2 lookup behavior.

Syslogs:

None

----------------------------------------------------------------

embryonic-conn-limit

Connection limit reached

A new connection was dropped because it would exceed a configured connection limit. This counter increments when the maximum number of simultaneous connections allowed by a service policy has been reached. Connection limits are configured using Modular Policy Framework with the 'set connection conn-max' command (for global limits) or 'set connection per-client-max' (for per-host limits). These limits apply to all connection types: TCP, UDP, and SCTP. This drop occurs during connection establishment when the device is already tracking the maximum allowed number of active connections for the matched traffic class. Note that this counter is distinct from embryonic connection limits, which trigger TCP intercept behavior rather than immediate drops. In cluster deployments, the limit check includes connections tracked across all cluster members.

Recommendation:

Check syslog message 201011 to identify which host or traffic class is hitting the limit and whether it is a global or per-client limit. Use 'show service-policy' to view current connection counts and configured limits for each policy. If the traffic is legitimate, increase the connection limit using 'set connection conn-max' or 'set connection per-client-max' in the appropriate service policy. If the limit is being hit by a single host, verify whether it represents normal application behavior (such as a busy web server) or a potential connection flood attack. For attack scenarios, consider lowering per-client limits or implementing rate limiting. In versions prior to 9.20.4.14 and 9.24.1, note that the drop counter in 'show service-policy' may not increment correctly even though drops are occurring; rely on syslog 201011 for accurate drop tracking in those releases.

Syslogs:

201011

----------------------------------------------------------------

eve-handler

Blocked or blacklisted by the eve-handler

This counter is reserved for packets dropped by the Snort inspection engine's EVE (Extensible Event Format) handler. EVE is Snort's JSON-based event logging output format. However, in current FTD releases, this counter is not actively incremented. Snort blacklist verdicts—such as those from the reputation preprocessor, file analysis, or intrusion rules configured to block traffic—are tracked under separate, more specific drop counters. If you observe increments on this counter, it may indicate an internal diagnostic or development feature, or a transient condition during Snort engine initialization or reconfiguration.

Recommendation:

This counter is not expected to increment during normal operation. If you see drops attributed to eve-handler, first verify that other Snort-related drop counters (such as 'snort-blacklist' or 'reputation') are not incrementing instead—these are the standard counters for Snort block verdicts. Check the output of 'show asp drop' for other Snort-related drops, and review 'show snort statistics' to confirm Snort is processing traffic normally. If this counter increments persistently or correlates with traffic loss, enable packet-tracer or capture with trace to identify the exact verdict and rule triggering the drop, then contact Cisco TAC with the diagnostic output and a description of the affected traffic pattern.

Syslogs:

None.

----------------------------------------------------------------

failed-to-setup-pdts-flow-param

Insufficient buffer space for Snort inspection message

This counter increments when the firewall cannot prepare a packet for deep packet inspection by the Snort engine due to insufficient buffer headroom. The data plane needs to prepend message headers (approximately 122 bytes) to packets before sending them to Snort for inspection. If the packet buffer does not have enough space in front of the packet data, the setup fails and the packet is dropped. This most commonly occurs when NAT64 translation (IPv4 to IPv6) has already consumed front-of-packet buffer space by expanding the IP header from 20 to 40 bytes, leaving insufficient room for the inspection message headers. The issue can also occur with other features that consume buffer headroom before packets reach the inspection path.

Recommendation:

Check if NAT64 is configured and active on the traffic path where drops occur. If NAT64 is in use, upgrade to a release that includes the buffer headroom fix (FTD 7.6.2+, FXOS 2.16.2+, or later). Review the traffic pattern: if drops occur primarily on return traffic (IPv4→IPv6 direction) after NAT64 translation, this confirms the headroom issue. If NAT64 is not involved, examine other features in the traffic path that might consume buffer space before inspection (encapsulation, tunneling, or header manipulation). Enable 'debug pdts 7' to see detailed PDTS setup failures. If drops persist after upgrading or NAT64 is not in use, contact Cisco TAC with packet captures and the output of 'show asp drop' and 'show asp inspect-dp snort counters'.

Syslogs:

None

----------------------------------------------------------------

file-process

File blocked by file policy or malware detection

This counter increments when the deep packet inspection engine blocks a file transfer based on file policy rules or malware detection. The block occurs when traffic matches a configured file policy that specifies a block action for the detected file type, or when malware analysis (including cloud lookups and local malware detection) determines the file should be blocked. This applies to file transfers over application protocols such as HTTP, HTTPS, FTP, SMTP, POP3, IMAP, and SMB. The counter reflects enforcement of file type restrictions, malware blocks, and file reputation-based blocks configured in your access control policy's file and malware policies. On FTD devices, this is the primary counter for file policy enforcement actions.

Recommendation:

Review your file policy configuration to confirm the block is intentional. Use packet tracer to identify which file policy rule triggered the block and see details about the file (type, name, SHA-256 hash if available). Check connection events and file events in the management center to see the disposition (malware, custom detection, file type block). If legitimate files are being blocked, adjust your file policy rules to allow the specific file type or create exceptions for trusted sources. For malware blocks, verify the file's reputation using the SHA-256 hash. If the block is unexpected, confirm that both the IPS and Malware Defense licenses are active on the device. For FTP transfers that appear to hang or timeout, this may indicate a file policy is inspecting the transfer; review historical defects related to FTP file inspection if issues persist.

Syslogs:

None. File policy actions generate connection events and file events visible in the management center, but do not produce syslogs on the device itself.

----------------------------------------------------------------

firewall

Blocked by Snort inspection engine

This counter increments when the Snort inspection engine blocks a packet because it cannot associate the packet with an established connection, or because the connection has been marked for blocking by the stateful inspection logic. This typically occurs when a packet arrives but no corresponding flow entry exists in the connection table—either because the flow was never created (e.g., the initial handshake was missed or dropped), the flow was removed due to memory pressure or timeout, or the flow state was lost during a high-availability failover. In some cases, mid-session packets arriving out of sequence or after flow table pruning will trigger this drop. The inspection engine applies a default-deny verdict when it cannot validate the packet against an active connection.

Recommendation:

First, verify whether the drops correlate with memory pressure by checking 'show snort status' for flow table utilization and memory statistics. If flow tables are near capacity or memory pruning is occurring, consider tuning connection limits or investigating memory leaks. For high-availability deployments, check whether drops coincide with failover events—connection state synchronization issues can cause legitimate traffic to be blocked immediately after switchover. Use packet-tracer to simulate the dropped traffic and examine the inspection verdict; enable 'debug snort' to see detailed flow lookup failures. If drops are sporadic and low-volume, they may represent legitimate blocking of packets that arrived without proper connection setup (e.g., stray ACKs or mid-stream injections). Persistent high drop rates require investigation of flow creation failures, memory exhaustion, or policy misconfigurations preventing initial connection establishment.

Syslogs:

None

----------------------------------------------------------------

flow-being-freed

Flow is being freed

This counter increments when a connection is being torn down and packets that were queued for control plane processing must be discarded. During normal operation, some packets are temporarily queued for inspection, authentication, or other control plane services. If the connection terminates (due to timeout, RST/FIN, policy change, or other reasons) while packets are still waiting in the queue, those packets are dropped as part of cleanup. This is expected behavior and indicates proper resource management during connection teardown.

Recommendation:

No action is required. This counter reflects normal cleanup operations when connections end. Packets queued for control plane processing are discarded because the flow they belong to no longer exists. If this counter is incrementing rapidly alongside other drop counters (such as ACL denies, inspection drops, or flow creation failures), investigate those primary drop reasons first—they indicate why flows are being terminated. This counter is a secondary effect of those terminations, not a root cause.

Syslogs:

None

----------------------------------------------------------------

flow-expired

Expired flow

The firewall attempted to process a packet for a connection that has already timed out and been removed from the connection table. This most commonly occurs when packets return from external inspection services (such as Snort intrusion detection, Firepower threat defense inspection, or content security scanning) after the connection has expired due to inactivity. The delay introduced by deep inspection can exceed the configured connection timeout, especially for idle connections. This counter also increments when the firewall attempts to send a TCP reset for a connection that has already expired, or when forwarding packets that reference flows no longer in the connection table.

Recommendation:

Review connection timeout settings for the affected traffic class using 'show timeout' and 'show conn detail'. If legitimate long-lived connections with intermittent traffic are timing out during inspection, increase the appropriate timeout value (e.g., 'timeout conn' for general connections, or protocol-specific timeouts). Verify inspection policy configuration - overly aggressive deep packet inspection on high-latency or low-throughput connections may cause packets to queue long enough for flows to age out. Check 'show service-policy' to identify which inspection engines are active. If drops correlate with specific traffic patterns, consider adjusting timeout values for those connection types or excluding low-risk traffic from deep inspection. Occasional increments during normal operation are expected and benign, particularly during connection teardown sequences. Investigate further only if the counter increases rapidly or correlates with user-reported connectivity issues.

Syslogs:

None.

----------------------------------------------------------------

flow-expired-drop

Flow expired during packet injection

The firewall attempted to inject a packet into the data path for a connection that has already expired and been removed from the connection table. This occurs when a packet that was previously deferred for asynchronous processing is ready to resume, but the original flow is no longer active. Common scenarios include: packets returning from Snort inspection after the flow timed out, TCP intercept operations where embryonic connections expire during SYN retransmissions, cached packets being replayed after the flow has been removed, or RST packets being generated for connections that have already closed. The packet is dropped because there is no valid flow context to continue processing.

Recommendation:

This counter typically indicates normal operation when flows expire during legitimate timeout periods. Investigate if the counter is incrementing rapidly or if applications are experiencing connection failures. Check whether timeout values are appropriate for your traffic patterns—if legitimate long-running connections or slow applications are being prematurely terminated, consider increasing the relevant timeout values (TCP timeouts, embryonic connection timeouts, or inspection timeouts). For TCP intercept scenarios, verify that backend servers are responding promptly to SYN packets. If the counter correlates with Snort inspection, check Snort performance and whether inspection is introducing excessive delays. Use 'show conn' to verify current timeout settings and 'show asp drop' to monitor the rate of these drops.

Syslogs:

None

----------------------------------------------------------------

flow-out-of-memory

Flow Out of Memory

The device failed to allocate memory for a new connection and dropped the packet. This occurs when the system attempts to create a connection entry but cannot obtain the required memory from the connection cache pool. The failure can happen for several reasons: the device has reached its configured connection limit (per-context, per-interface, or system-wide), the global memory pool is exhausted, or memory allocation is delayed during sustained high connection rates. When connection limits are configured, the system first attempts to reclaim preemptable connections before dropping new traffic. For management traffic (to/from the device itself), connection limits are bypassed but memory allocation can still fail if system memory is critically low. This counter is distinct from resource manager connection limit drops—it specifically indicates a memory allocation failure during connection structure creation.

Recommendation:

Check current connection counts against configured limits using 'show conn count' and 'show resource usage'. Review system memory with 'show memory' and 'show memory detail' to identify if global memory is exhausted. If connection counts are well below limits but this counter is incrementing, investigate memory fragmentation or allocation delays—particularly on high-throughput platforms processing tens of thousands of connections per second, where memory pool expansion can introduce 200-500ms delays (see CSCwd60102). Check for syslog 302311 which accompanies this drop and reports the app-cache memory threshold status. If memory is healthy and limits are not reached, consider whether a memory leak is consuming available memory over time. For multi-context deployments, verify per-context memory allocation is balanced. If the issue occurs during traffic bursts, evaluate whether connection rate limiting or connection timeout tuning can reduce peak memory demand. Contact TAC if drops persist with adequate memory and connection headroom, as this may indicate a memory accounting bug (see CSCwk46737 for HA-specific scenarios).

Syslogs:

302311

----------------------------------------------------------------

fo-standby

Dropped by standby unit

This counter increments when a packet arrives on a standby unit or in a standby security context and would require creating a new connection. In a high-availability deployment, only the active unit or active context processes through-the-box traffic and maintains connection state. When a packet arrives on the standby side that does not match an existing replicated connection, the standby drops it rather than creating a new flow entry. This is by design: standby units do not independently establish connections for transit traffic, as doing so would create state inconsistencies when failover occurs. Traffic destined to the appliance itself (management traffic) is exempt from this drop and is processed normally on both active and standby units.

Recommendation:

This counter incrementing on the standby unit or standby context is normal and expected behavior. It typically indicates asymmetric routing, where some packets in a flow are reaching the standby instead of the active unit. Common causes include: (1) upstream routing or load-balancing sending packets to the wrong unit, (2) return traffic taking a different path than forward traffic, or (3) multicast or broadcast traffic received on both units. If this counter increments on the active unit or active context, investigate immediately—this indicates a failover state detection problem. To troubleshoot: verify failover status with 'show failover' and confirm which unit is active for each context; check for asymmetric routing in upstream devices; review interface configurations to ensure proper failover link and data interface settings. In rare cases, internal traffic such as logging packets may incorrectly trigger this counter due to software defects (see CSCwf73036 for an example). If the counter increments rapidly on the standby and you suspect it is not due to asymmetric routing, collect packet captures on the standby unit to identify the traffic type.

Syslogs:

302014, 302016, 302018

----------------------------------------------------------------

fragment-full-reassembly-failed

Fragment Full Reassembly Failed

This counter increments when the device cannot allocate sufficient memory to reassemble fragmented packets into a single contiguous packet. This occurs specifically when traffic exits through a passive interface or inline set configured for identity firewall monitoring. These interface types require full reassembly (combining all fragments into one complete packet) rather than virtual reassembly, which demands a larger contiguous memory buffer. The allocation can fail either due to general memory exhaustion or when the system reaches its limit for large buffer allocations (a safeguard against resource exhaustion). When this counter increments, all fragments in the chain are dropped.

Recommendation:

Check current memory utilization with the 'show blocks' command, focusing on the availability of large memory blocks. If memory is consistently low, investigate potential memory leaks or consider reducing traffic load. If this counter increments frequently on devices with passive interfaces or inline sets, verify that fragmented traffic patterns are expected for the monitored applications. In high-traffic environments with significant fragmentation, consider whether passive monitoring is necessary for all traffic or if it can be scoped more narrowly. If memory appears adequate but drops persist, contact Cisco TAC as the system may be hitting internal limits on large buffer allocations designed to prevent resource exhaustion.

Syslogs:

321007

----------------------------------------------------------------

fragment-reassembly-failed

Fragment reassembly failed

The appliance was unable to reassemble fragmented IP packets and dropped all fragments in the chain. Reassembly can fail for several reasons: the fragment database limit was exceeded (default 200 concurrent fragment sets), a fragment chain contained too many pieces (limit 24 fragments per packet), fragments timed out before all pieces arrived (default 5 seconds), the total reassembled size would exceed 65,535 bytes, or in TrustSec deployments, fragments arrived with mismatched Security Group Tags. Additional causes include malformed MPLS-encapsulated fragments, double VLAN-tagged fragments, or internal fragment queue corruption. This counter aggregates all reassembly failure types; use the detailed per-interface statistics to identify the specific cause.

Recommendation:

Run 'show fragment' to view per-interface reassembly statistics and identify the specific failure type (Size overflow, Timeout, Chain overflow, Fragment queue threshold exceeded, or SGT mismatch). If Size overflow counters are incrementing, increase the fragment database size using the 'fragment size' command (default 200). If Timeout counters are high, fragmented traffic is experiencing excessive delay or packet loss between the source and the appliance. If Chain overflow is incrementing, a device is fragmenting packets into more than 24 pieces; investigate the source and consider increasing MTU along the path. If the fragment queue shows an invalid value (4294967295) with Size overflow drops, this indicates a software defect requiring interface reconfiguration or upgrade. Check for accompanying syslogs 209003 (database limit), 209004 (invalid size), or 209005 (too many fragments). In MPLS or complex VLAN environments, verify that the appliance correctly parses encapsulation headers. If drops persist without clear cause, collect 'show fragment', 'show asp drop', and packet captures for TAC analysis.

Syslogs:

209003, 209004, 209005

----------------------------------------------------------------

ftp

Dropped by Snort FTP preprocessor inspection

This counter increments when the Snort inspection engine drops a packet based on FTP preprocessor analysis. This is distinct from native FTP inspection drops shown in 'show service-policy inspect ftp' statistics. The Snort FTP preprocessor examines FTP control channel traffic for protocol anomalies, malformed commands, or policy violations configured in the intrusion policy. Common triggers include FTP commands with embedded exploits, protocol violations detected by Snort rules, or traffic matching FTP-related intrusion signatures. This counter appears on FTD platforms where Snort inspection is active; it does not apply to standalone ASA devices without threat detection services.

Recommendation:

Use packet-tracer or enable ASP capture with trace to see the detailed Snort verdict and the specific reason for the drop. Review 'show snort' output to check Snort instance health and queue status. Examine the intrusion policy applied to the traffic to identify which FTP-related rule or preprocessor setting triggered the drop. If legitimate FTP traffic is being blocked, consider tuning the intrusion policy by adjusting FTP preprocessor settings or creating exceptions for specific rules. For troubleshooting, correlate this counter with Snort event logs in the FMC to identify the specific signature or preprocessor check that caused the drop. If the counter increments without corresponding Snort events or during normal FTP operations, contact Cisco TAC for further analysis.

Syslogs:

None directly associated with this counter. Snort drops may generate intrusion events visible in FMC event logs.

----------------------------------------------------------------

geneve-dual-arm-no-data-saved

Geneve dual-arm mode missing saved peer information

This counter increments when the firewall is deployed behind an AWS Gateway Load Balancer in dual-arm mode and attempts to send return traffic back through the Geneve tunnel, but cannot find the saved peer VTEP information needed to construct the outer Geneve header. In dual-arm mode, traffic from the AWS GWLB arrives encapsulated in Geneve, is inspected by the firewall, and internet-bound traffic exits directly via the outside interface. Return traffic from the internet must be re-encapsulated with Geneve and sent back to the GWLB, which requires the peer VTEP MAC address and IP address that were extracted from the original inbound Geneve packet. This information is normally saved in the connection structure during inbound processing. The drop occurs when this saved data is missing, typically because no connection was established when the inbound Geneve packet was processed, or the connection was prematurely released before the return packet arrived.

Recommendation:

This counter indicates a state synchronization issue in AWS GWLB dual-arm deployments. Verify that connections are being properly established for inbound traffic from the GWLB. Check for drops or errors on the inbound path that might prevent connection creation (review other ASP drop counters, particularly Geneve-related drops). Ensure the firewall has sufficient memory and connection table capacity. If the issue persists during normal traffic patterns, collect packet captures on both the GWLB-facing interface and the outside interface, along with 'show conn detail' output, and contact Cisco TAC. This is specific to AWS GWLB dual-arm deployments and does not apply to single-arm (U-turn) mode or standard Geneve tunnels.

Syslogs:

None.

----------------------------------------------------------------

geneve-encap-error

Geneve Encapsulation Failed

This counter increments when the device cannot add Geneve tunnel headers to an outbound packet. The encapsulation process fails for one of two reasons: (1) the resulting encapsulated packet would exceed either the configured VTEP interface MTU or the maximum supported frame size, or (2) insufficient buffer space exists in the packet structure to prepend the required Geneve, UDP, IP, and Ethernet headers. This drop occurs during egress processing when traffic is being sent through a Geneve VTEP interface to a remote peer, including AWS Gateway Load Balancer (GWLB) deployments where FTD/ASA acts as a security appliance behind the GWLB. The encapsulation adds approximately 50-70 bytes of overhead (Ethernet + IP + UDP + Geneve headers), so packets near the MTU limit are particularly susceptible. Buffer space errors typically indicate internal packet handling issues rather than configuration problems.

Recommendation:

First, verify the VTEP interface MTU is properly configured to accommodate the Geneve overhead. Use 'show running-config interface' to check the MTU on the VTEP interface—it should be at least 50 bytes larger than the largest expected inner packet. For AWS GWLB deployments, ensure the MTU settings align with AWS network requirements (typically 1500 bytes for the inner packet, requiring a VTEP MTU of at least 1550). If MTU is correctly configured and drops persist, check 'show interface' statistics for the VTEP interface to confirm it is operational. Capture packets on the VNI interface using 'capture' commands to identify which traffic is triggering the drops—look for unusually large packets or fragmented traffic. If drops occur sporadically with normal-sized packets, this may indicate a software defect related to buffer management; collect 'show tech-support' and contact Cisco TAC, especially if running AWS GWLB configurations. For consistent drops with large packets, consider enabling Path MTU Discovery on upstream devices or reducing the MSS for TCP connections using the 'sysopt connection tcpmss' command.

Syslogs:

None.

----------------------------------------------------------------

geneve-invalid-header

Geneve header validation failure

The security appliance received a UDP packet on the Geneve destination port (typically 6081) but could not successfully decode the Geneve encapsulation header. This occurs when the header fails validation checks required by RFC 8926, including: an unsupported version number (only version 0 is valid), inconsistent or invalid option length fields, a critical bit flag set without corresponding critical options in the header, or option lengths that exceed protocol limits or do not align correctly. This counter increments for both Geneve traffic destined to the appliance (decapsulation on a VTEP interface) and Geneve traffic being inspected as it passes through the appliance. The drop protects against malformed encapsulation that could cause processing errors or security issues.

Recommendation:

Verify that all Geneve tunnel endpoints are using RFC 8926-compliant implementations with version 0 headers. Check for packet corruption on the network path between tunnel endpoints—consistent drops may indicate MTU issues, faulty network equipment, or bit errors. If the appliance is deployed behind an AWS Gateway Load Balancer, ensure the GWLB configuration and any intermediate network devices are not modifying Geneve headers. Use packet capture on the ingress interface to examine the actual Geneve header structure and identify which validation check is failing (version field, option length, or critical bit mismatch). If drops occur only for specific tunnel peers, investigate the Geneve implementation on those endpoints. Occasional drops may be benign if caused by transient corruption, but sustained or high-volume drops indicate a configuration or interoperability problem that requires remediation.

Syslogs:

860004

----------------------------------------------------------------

geneve-invalid-header-thru-traffic

Invalid Geneve header format for through-the-box traffic

The appliance received a UDP packet on the Geneve port (6081) but could not successfully parse the Geneve encapsulation header. This occurs when the header fails validation checks, such as an unsupported version number (only version 0 is valid), malformed variable-length options (inconsistent option lengths, total options exceeding the maximum allowed size), or critical-bit violations (the critical bit is set in the header flags but no critical options are present in the options section). This counter applies only to transit traffic passing through the appliance for inspection, typically in cloud environments where Geneve encapsulation is used for network virtualization overlays. Common deployment scenarios include AWS Gateway Load Balancer (GWLB) integrations with FTDv or ASAv instances, where traffic is encapsulated in Geneve tunnels between the load balancer and the security appliance.

Recommendation:

Verify that the upstream device sending Geneve-encapsulated traffic is using RFC 8926-compliant Geneve headers with version 0. If the appliance is deployed behind an AWS Gateway Load Balancer, confirm that the GWLB configuration and health checks are functioning correctly. Use packet capture on the ingress interface to examine the Geneve header structure and identify which validation check is failing. Check for mismatched MTU settings that could cause truncated headers. If the issue persists and traffic is being dropped incorrectly, collect the output of 'show asp drop', packet captures showing the malformed headers, and the appliance configuration, then contact Cisco TAC for further analysis.

Syslogs:

860008

----------------------------------------------------------------

geneve-invalid-nve-peer

Geneve packet from unconfigured or mismatched NVE peer

The device received a Geneve-encapsulated packet from a source IP address that does not match the statically configured NVE (Network Virtualization Endpoint) peer. This counter increments only when the receiving VTEP interface has a static peer configured using the 'peer ip' command in NVE configuration mode, and the outer source IP of the incoming Geneve packet differs from that configured peer address. This is a security check that enforces strict peer validation when static peer discovery is in use, preventing the device from accepting overlay traffic from unauthorized tunnel endpoints. The check occurs during Geneve decapsulation before the inner packet is processed. This counter does not increment when using multicast-based peer discovery or peer-group configurations, as those modes do not enforce source IP validation.

Recommendation:

Verify the NVE peer configuration on both ends of the tunnel. Use 'show nve peers' to display the configured static peer and 'show asp drop' to confirm the drop counter is incrementing. Check that the remote VTEP is using the correct source IP address that matches your local 'peer ip' configuration. If the remote peer IP has changed, update the local NVE configuration accordingly. If you are using a topology with multiple potential peer sources (such as a cluster or load-balanced environment), consider switching from static 'peer ip' configuration to 'peer-group' with a network object containing all valid peer addresses, or use multicast-based peer discovery if your network supports it. This drop is expected and benign when it blocks traffic from unauthorized sources; contact TAC if legitimate Geneve traffic is being dropped.

Syslogs:

860007

----------------------------------------------------------------

geneve-invalid-udp-checksum

GENEVE packet dropped due to invalid UDP checksum

The security appliance received a GENEVE-encapsulated packet with an incorrect UDP checksum in the outer header and dropped it during decapsulation. GENEVE uses UDP as the transport protocol, and when the UDP checksum field contains a non-zero value, the device validates it against the calculated checksum. If the values do not match, the packet is dropped and this counter increments. A UDP checksum of zero is permitted by RFC 8926 and indicates that no checksum was computed by the sender; such packets are accepted without validation. This drop occurs during ingress processing on the VTEP interface before the inner payload can be extracted. The counter typically increments due to network corruption in transit, NIC hardware checksum offload issues on the sending device, or software bugs in the encapsulating endpoint. On virtual platforms (FTDv, ASAv), checksum validation is always performed in software because hardware offload flags may not be reliably set by virtual NICs. In AWS Gateway Load Balancer (GWLB) deployments, earlier software versions incorrectly rejected valid zero-checksum packets from the GWLB; this was resolved in version 9.18.3.53 and later.

Recommendation:

Check the syslog message 860006 to identify the source IP address of the GENEVE peer sending packets with bad checksums. If the counter is incrementing steadily, verify network health between the VTEP peers—look for physical layer issues, switch problems, or MTU mismatches that could cause packet corruption. On the sending device, confirm that UDP checksum offload is functioning correctly; misconfigurations or driver bugs can result in incorrect checksums being transmitted. If you are running FTDv in AWS behind a Gateway Load Balancer and see this counter on versions earlier than 9.18.3.53, upgrade to a fixed release (CSCwd63722, CSCwf62885). For virtual platforms experiencing this issue, verify that the hypervisor and virtual NIC drivers are up to date. Occasional drops may be benign and caused by transient network errors, but sustained increments indicate a persistent problem requiring investigation. Capture packets on both the sending and receiving VTEP interfaces to confirm whether checksums are correct when transmitted or corrupted in transit. If the issue persists after ruling out network and hardware problems, contact Cisco TAC with the syslog output and packet captures.

Syslogs:

860006

----------------------------------------------------------------

geneve-invalid-vni-mcast-ip

Missing Multicast Group on GENEVE VNI Interface

The device attempted to encapsulate a packet for transmission through a GENEVE tunnel, but the VNI interface lacks the multicast group configuration required for the operation. This occurs when the device needs to send broadcast, multicast, or unknown unicast traffic through a GENEVE tunnel without a configured static peer, and the VNI interface does not have a multicast group IP address configured. GENEVE tunnels require either a static peer IP address or a multicast group for forwarding traffic to remote tunnel endpoints. When neither is configured, packets destined for broadcast addresses, multicast MAC addresses, or non-IP/non-ARP traffic cannot be forwarded because the device has no way to determine the destination tunnel endpoint.

Recommendation:

Configure a multicast group IP address on the VNI interface using the 'mcast-group' command, or configure a static peer VTEP using the 'peer ip' command under the NVE interface. If you are using GENEVE for point-to-point tunneling, static peer configuration is the typical deployment model. If you are deploying GENEVE in a multi-destination environment (requiring broadcast, multicast, or unknown unicast forwarding), verify that your platform and software version support multicast-based GENEVE peer discovery, as this feature may not be available in all releases. Check 'show nve peers' to verify peer configuration and 'show interface vni' to confirm VNI interface settings. If drops persist after configuration, verify that the multicast group is reachable and that multicast routing is properly configured on the underlay network.

Syslogs:

None.

----------------------------------------------------------------

geneve-missing-peer-vtep-ip

Geneve Peer VTEP IP Not Found

This counter increments when the device cannot determine the remote VTEP (Virtual Tunnel Endpoint) IP address needed to encapsulate and forward a packet through a Geneve tunnel. When traffic exits through a VNI (VXLAN Network Identifier) interface, the device must identify which remote VTEP hosts the destination endpoint. This lookup can fail in several scenarios: in routed firewall mode, the device performs an adjacency lookup based on the inner destination IP address; in transparent firewall mode, it consults the Layer 2 MAC address table for the destination MAC. If neither a static peer is configured nor a dynamic mapping has been learned (through prior decapsulated traffic or control-plane signaling), the encapsulation path has no VTEP IP to use as the outer destination, and the packet is dropped. This counter applies to both Geneve and VXLAN encapsulation paths, as they share the same peer discovery logic.

Recommendation:

Check the VTEP mapping tables to confirm whether the device has learned the remote VTEP IP for the destination endpoint. Use 'show arp vtep-mapping' (for IPv4 endpoints), 'show mac-address-table vtep-mapping' (for Layer 2 bridged traffic), or 'show ipv6 neighbor vtep-mapping' (for IPv6 endpoints) to verify that an entry exists for the inner destination address. If no mapping is present, verify that the remote VTEP is reachable and that traffic from the remote endpoint has been received and decapsulated (which triggers dynamic learning). For static peer configurations, confirm that the peer VTEP IP is correctly configured on the NVE interface. In routed mode, verify that a valid route exists for the inner destination network and that adjacency resolution is functioning. In transparent mode, ensure that the destination MAC has been learned in the bridge group. If the remote endpoint is newly provisioned or the device has recently rebooted, allow time for the mapping to be learned through bidirectional traffic. Persistent drops may indicate a routing or reachability issue preventing the device from learning the remote VTEP, or a misconfiguration in the overlay network topology.

Syslogs:

None.

----------------------------------------------------------------

ha-nlp-invalid-fragments

Fragmented packet exceeds failover link MTU

This counter increments when a fragmented packet received on the internal management tap interface exceeds the maximum supported size for transmission over the failover link. The failover link enforces a maximum MTU of 1350 bytes to accommodate all protocol headers (Layer 2, transport, and high-availability encapsulation). When a fragment arrives that would exceed this limit after accounting for all overhead, the packet is dropped to prevent transmission failures. This typically affects management traffic from FDM (Firepower Device Manager) or other control-plane applications that use the failover link for communication between high-availability peers. The tap interface has a default MTU of 1300 bytes for payload, but when Layer 2 headers and encapsulation are added, the total frame size can approach or exceed the 1350-byte limit, triggering this drop.

Recommendation:

This counter usually indicates a Path MTU Discovery (PMTU) issue or misconfiguration in the management network path. First, verify that the failover link interfaces have sufficient MTU configured (at least 1500 bytes recommended to avoid fragmentation). Check for intermediate devices (switches, routers) between the high-availability peers that may be fragmenting management traffic. If the counter increments frequently, examine the source of large management packets—this may include certificate exchanges, configuration synchronization, or bulk updates. For FDM-managed devices, ensure the management interface MTU is properly configured and that no intermediate network devices are forcing fragmentation. In most cases, this is a transient condition during initial synchronization or certificate operations and does not affect data-plane traffic. If the counter grows continuously, contact Cisco TAC with the output of 'show failover' and 'show interface' for both units, as this may indicate a persistent MTU mismatch in the management path.

Syslogs:

None

----------------------------------------------------------------

ha-nlp-lu-link-not-ready

Stateful failover link not ready to process traffic

The stateful failover link received a packet but the link is not yet operationally ready to process state replication traffic. This occurs when the physical interface is up but the pair has not completed the state machine transitions required for active state synchronization. Common scenarios include: the standby unit is still in initial synchronization states (cold, config, or bulk sync) and has not yet reached standby-ready; the active unit is sending state updates before the peer has signaled readiness; or the stateful link has just recovered from a failure and the state machine is re-establishing the replication channel. The counter may increment briefly during normal failover events such as unit boot, configuration synchronization, or stateful link flapping, and should clear once both units reach stable active/standby-ready states.

Recommendation:

Check the current failover state on both units with 'show failover state'. If the standby unit is progressing through normal initialization states (cold, config, bulk), these drops are expected and will stop once it reaches standby-ready. If the counter increments continuously while both units report stable states, verify the stateful failover link configuration with 'show failover' and confirm the interface is fully operational on both sides. Check for physical layer issues, interface flapping, or mismatched MTU settings on the stateful link. Review 'show failover history' for recent state transitions or link recovery events. Persistent increments in a stable pair may indicate state machine synchronization issues; collect 'show tech-support' from both units and contact Cisco TAC.

Syslogs:

None

----------------------------------------------------------------

ha-nlp-send-ha-msg-err

Failed to send packet over HA failover link

This counter increments when the firewall fails to transmit a packet over the High Availability failover link. The failure occurs during internal state replication between HA peers after the packet has been received from the internal HA tap interface, rate-limited, and prepared for transmission. The packet is dropped because the final transmission step failed, typically due to failover link congestion, buffer resource exhaustion, internal locking contention, or transport layer errors on the HA link itself. This counter tracks failures in the Network Layer Protocol (NLP) replication mechanism used to synchronize state between active and standby units in a failover pair.

Recommendation:

Check the physical and logical status of the failover link using 'show failover' and verify that both the failover interface and stateful failover link (if configured) show as operational. Use 'show interface' on the failover link interface to check for errors, drops, or link flapping. Review 'show failover history' to determine if recent failover events correlate with these drops. If this counter is incrementing steadily, investigate failover link bandwidth utilization and consider increasing the link capacity or MTU if the link is congested. Check for any physical layer issues such as cable problems, duplex mismatches, or switch port errors. If the counter increments occasionally during high traffic periods, this may indicate temporary resource contention and is typically self-correcting. Persistent or rapidly increasing counters indicate a problem with the failover link infrastructure that requires immediate attention, as it can prevent proper state synchronization between HA peers and lead to connection failures during failover events.

Syslogs:

None

----------------------------------------------------------------

hop-limit-exceeded

Hop Limit Exceeded

The security appliance received an IPv6 packet with a hop limit value of zero. The hop limit field in IPv6 headers is decremented by one at each router hop; when it reaches zero, the packet has exhausted its allowed path length and must be dropped to prevent routing loops. This counter increments when the appliance receives IPv6 packets that have already reached hop limit zero before arriving. This is the IPv6 equivalent of the TTL exceeded condition in IPv4. Note that per RFC 8200, packets with hop limit zero that are destined directly to the appliance itself (not being routed through it) are processed normally and do not increment this counter.

Recommendation:

This drop is typically benign and indicates normal routing behavior—either a routing loop elsewhere in the network has been prevented, or packets are arriving from distant sources that have exhausted their hop limit. Investigate if the counter is incrementing rapidly: check for routing loops in your IPv6 network topology using traceroute, verify that static and dynamic IPv6 routes are configured correctly, and confirm that upstream devices are not forwarding packets with abnormally low initial hop limits. If the drops correspond to legitimate traffic that should reach the appliance, verify the routing path length and ensure intermediate routers are not misconfigured. Use packet captures to identify the source addresses and determine whether the traffic represents a misconfiguration or an expected network boundary condition.

Syslogs:

None.

----------------------------------------------------------------

host-move-pkt

Host moved between interfaces

This counter increments when the device is operating in transparent firewall mode and detects that a source MAC address, already learned on one interface, appears on a different interface. When a packet arrives with a source MAC that is bound to a different interface in the Layer 2 forwarding table, the device drops the packet and sends a notification to update the MAC table. This behavior protects against MAC address table inconsistencies during the brief period while the table is being updated. The drop is temporary—subsequent packets from the same host on the new interface will be forwarded once the MAC table update completes. This mechanism applies to both standalone transparent mode and routed mode with Bridge Virtual Interfaces (BVI).

Recommendation:

Occasional increments are normal when hosts physically move between network segments or during network topology changes such as spanning-tree convergence. However, if this counter increments rapidly or continuously for the same MAC address, it indicates a network loop or duplicate MAC address condition. Check for Layer 2 loops by verifying spanning-tree topology with 'show spanning-tree' on upstream switches. Review syslog messages 412001 to identify which MAC addresses are moving and between which interfaces. If the same MAC address repeatedly toggles between two interfaces, investigate cabling, switch port configuration, or the possibility of MAC spoofing. In high availability deployments, ensure that failover interface MAC addresses are properly configured to avoid drops of failover control traffic. For environments with frequent legitimate host mobility (such as wireless roaming or VM migration), this behavior is expected and benign.

Syslogs:

412001, 322001

----------------------------------------------------------------

ids-pkts-processed

Packets processed in IDS monitoring modes

This counter increments for every packet processed on interfaces configured in inline-tap or passive IDS mode. These interface modes are designed for traffic monitoring and intrusion detection visibility only—packets are inspected by the threat detection engine but are not forwarded through the device. After inspection completes, all packets are dropped by design, and this counter tracks that expected behavior. This counter appears only on FTD platforms with inline interface pairs configured in tap mode or passive monitoring mode.

Recommendation:

This is normal, expected behavior for inline-tap and passive interface modes. The counter indicates the threat detection engine is successfully receiving and processing traffic for visibility and alerting. No action is required. If you need traffic to pass through the device (inline enforcement rather than monitoring), reconfigure the interface pair to inline mode instead of inline-tap or passive mode. To verify interface mode, use 'show inline-set' and check the 'Tap mode' field.

Syslogs:

None

----------------------------------------------------------------

ifc-classify

Shared interface packet classification failed

A packet arrived on a physical interface shared between multiple security contexts, but the system could not determine which context should process it. In multi-context mode, when multiple contexts share a physical interface, the device must classify each inbound packet to the correct context using either the destination MAC address or destination IP address. This drop occurs when both classification methods fail—the destination MAC does not match any context interface's MAC address, and the destination IP does not match any IP address configured on context interfaces sharing this physical interface. Common causes include: contexts sharing an interface without unique MAC addresses assigned, packets destined to IP addresses not explicitly configured on any context interface, or duplicate MAC addresses across contexts (often after upgrades with automatic MAC generation enabled).

Recommendation:

First, verify your multi-context shared interface configuration. Run 'show interface' in each context to confirm which interfaces are shared and check their MAC addresses for duplicates. If you are using automatic MAC address generation ('mac-address auto' in system context), ensure it is enabled and functioning—check 'show run all | include mac' from system context. If automatic generation is unavailable or problematic, manually assign unique MAC addresses to each context's shared interface using the 'mac-address' command in each context's interface configuration. For IP-based classification to work as a fallback, ensure that all IP addresses that should be reachable on shared interfaces are explicitly configured with 'ip address' or defined in NAT 'global' or 'static' statements within the appropriate context. If you see this drop counter incrementing during normal operation, it typically indicates a configuration gap—either missing unique MAC addresses or IP addresses not properly allocated to contexts. If the counter increments after a software upgrade in an Active/Active failover environment, check for duplicate MAC addresses (see CSCvw06298). Contact Cisco TAC if the issue persists after verifying MAC and IP configuration.

Syslogs:

None

----------------------------------------------------------------

ifc-not-cmd-enabled

Interface Not Configured for TrustSec SGT Tagging

The firewall received a packet with a Cisco TrustSec Security Group Tag (SGT) embedded in the Layer 2 header (using Cisco Meta Data encapsulation, EtherType 0x8909), but the ingress interface is not configured to accept SGT-tagged traffic. This occurs when packets arrive with inline SGT tags on an interface that does not have 'cts manual' configured. The firewall drops these packets because it cannot process the SGT information without explicit TrustSec configuration on the interface. This drop is a security measure to prevent unauthorized SGT propagation and ensure that only properly configured TrustSec links can exchange tagged traffic.

Recommendation:

If you expect TrustSec SGT-tagged traffic on this interface, configure 'cts manual' under the interface configuration to enable TrustSec processing. Use 'policy static sgt' to define how incoming SGT tags should be handled, and optionally configure 'propagate sgt' to control outbound SGT tagging. If you do not expect SGT-tagged traffic, investigate why upstream devices are sending TrustSec-encapsulated packets to this interface—this may indicate a misconfiguration on the sending device or an incorrect trust boundary in your TrustSec deployment. Identity and loopback interfaces are exempt from this check. If drops persist after proper configuration, verify that the TrustSec policy is correctly deployed across all devices in the trust domain.

Syslogs:

None

----------------------------------------------------------------

ike-sa-global-rate-limit

IPsec tunnel establishment request rate limit exceeded

This counter increments when traffic arrives that requires a new IPsec tunnel to be established, but the global rate limit for tunnel establishment requests has been exceeded. This occurs when the device receives traffic matching a dynamic crypto map configuration but no active tunnel exists yet. The device attempts to signal the key exchange process to negotiate a new tunnel, but if more than 10 such requests per second are generated across all crypto maps, additional requests are rate-limited and the triggering packets are dropped. This is a protective mechanism to prevent resource exhaustion during tunnel establishment storms, such as when many remote access clients connect simultaneously or when a large number of site-to-site tunnels need to be brought up at once.

Recommendation:

This counter incrementing is normal during periods of high tunnel establishment activity, such as after a device reload, during mass remote access client connections, or when many site-to-site tunnels are initializing. Brief increments are expected and benign—the rate limiting protects the control plane from overload. However, sustained or rapidly growing counts may indicate: (1) Tunnels repeatedly failing to establish and retriggering, suggesting configuration issues with crypto maps, tunnel groups, or peer reachability; (2) An unusually high number of simultaneous connection attempts; or (3) Traffic continuously arriving for destinations that should have tunnels but do not. Check tunnel establishment success with 'show crypto ikev1 sa' or 'show crypto ikev2 sa' and review any accompanying tunnel negotiation failure syslogs. If tunnels are establishing successfully, the drops are temporary and traffic will resume once tunnels are up. If establishment is failing, troubleshoot the underlying negotiation issue rather than the rate limit itself.

Syslogs:

None directly associated. Check for IKE negotiation failure syslogs (752xxx series) if tunnels are not establishing.

----------------------------------------------------------------

ike-sa-rate-limit

IPsec tunnel negotiation request rate limit exceeded

This counter increments when the device attempts to trigger IKE negotiation for a missing IPsec Security Association (SA) but the protective rate limit has been exceeded. When traffic matches a crypto map but no active tunnel exists, the device sends a request to the IKE process to establish the required SA. To prevent control-plane overload from repeated negotiation requests (for example, during a burst of traffic to multiple destinations or when a peer is unreachable), the device limits these requests to one per crypto map every 5 seconds. Packets that arrive during the rate-limit window are dropped and counted here. This behavior is most commonly observed in cluster deployments when a non-owner member receives traffic requiring VPN encryption and must signal the need for tunnel establishment. The rate limit is applied per crypto map entry, so different crypto maps can trigger independent negotiation requests.

Recommendation:

This counter indicates normal rate-limiting behavior and does not represent a configuration error. The dropped packets will be retransmitted by the sending application once the tunnel is established. If this counter increments frequently, verify that IPsec tunnels are establishing successfully and remaining stable—check for peer reachability issues, authentication failures, or mismatched crypto parameters that might cause repeated tunnel failures. In cluster environments, confirm that VPN traffic is being directed to the correct cluster member. High sustained values may indicate an application sending traffic faster than tunnels can be negotiated, or a peer that is intermittently unreachable. Review tunnel establishment logs and consider whether the traffic pattern is appropriate for site-to-site VPN (bursty traffic to many destinations may experience initial packet loss until tunnels are up).

Syslogs:

None

----------------------------------------------------------------

ike-spi-cookie-expired

IKEv2 packet with expired SPI timestamp in cluster

This counter increments when an IKEv2 packet is dropped because the timestamp embedded in its Security Parameter Index (SPI) is too old. This check only applies to clustered deployments running distributed site-to-site VPN, where each cluster member embeds a timestamp and member identifier into the IKE SPI to enable stateless load distribution and prevent replay attacks. The receiving member validates that the SPI timestamp is recent (within a threshold that tolerates up to one minute of clock skew between cluster members). Packets with stale timestamps are dropped to ensure proper cluster routing and security. The timestamp check is automatically disabled for the first 10 minutes after cluster initialization to allow VPN session synchronization to complete.

Recommendation:

This drop is expected only in clustered environments with distributed VPN enabled. Check syslog message 753001 for details about the source of the dropped packets. Common causes include: (1) Clock synchronization issues between cluster members—verify all members are using the same NTP server and their clocks are synchronized within one minute of each other; (2) Delayed or replayed packets arriving long after the original connection attempt; (3) Transient drops during the first 10 minutes after enabling clustering while VPN sessions are synchronizing. If drops persist after cluster stabilization and clocks are synchronized, the remote peer may be retransmitting very old packets due to network delays or connectivity issues. Verify network path stability between the peer and the cluster. If the peer is legitimate and drops continue, contact Cisco TAC for further investigation.

Syslogs:

753001

----------------------------------------------------------------

ike-spi-corrupted-value

IKEv2 packet with corrupted SPI in distributed VPN cluster

This counter increments when an IKEv2 packet is dropped during distributed VPN cluster operation because its Security Parameter Index (SPI) failed cryptographic validation. In distributed VPN mode, each cluster member embeds a timestamp and member identifier into the IKEv2 SPI using a cryptographic cookie mechanism. When a packet arrives, the receiving member validates the SPI by extracting and verifying the embedded information. The drop occurs when the member ID extracted from different parts of the SPI do not match, indicating the packet may have been corrupted in transit, replayed, or spoofed. This counter applies only to clusters configured with 'cluster vpn-mode distributed' and does not affect centralized VPN mode or standalone deployments.

Recommendation:

Check syslog message 753001 to identify the source IP address and port of the dropped packets. If drops are infrequent and transient, they may indicate normal network packet corruption or retransmitted stale packets and can typically be ignored. If drops persist or occur in high volume, investigate these potential causes: (1) Verify all cluster members have synchronized system clocks using NTP—time skew between members can cause SPI validation failures, though the system tolerates up to one minute of drift. (2) Check for network devices between the VPN peer and cluster that might be modifying packet contents (such as certain NAT implementations or middleboxes). (3) Rule out replay attacks or packet spoofing attempts from untrusted sources. (4) Verify the cluster is operating in spanned Ethernet mode, as distributed VPN mode is only supported with Layer 2 clustering. If the issue persists after these checks, collect 'show asp drop' output, syslog 753001 messages with timestamps, and contact TAC for further analysis.

Syslogs:

753001

----------------------------------------------------------------

inspect-dns-id-not-matched

DNS Response Transaction ID Mismatch

This counter increments when DNS inspection receives a response whose transaction identifier does not match any query that previously passed through the appliance on the same connection. The appliance tracks the transaction ID of each DNS query and validates that responses correspond to a known query. This validation is active when any of the following DNS inspection features are configured: dns-guard, id-randomization, or id-mismatch rate limiting. Common legitimate causes include DNS query timeouts (the query aged out before the response arrived), client retransmissions using different transaction IDs, or responses arriving significantly out of order. The counter may also increment during DNS cache poisoning attacks, where an attacker sends unsolicited responses with guessed transaction IDs attempting to inject false DNS records before the legitimate server responds.

Recommendation:

Occasional increments are normal in environments with slow or unreliable DNS servers, or when clients aggressively retransmit queries. If the counter increases steadily, check for DNS server performance issues or network latency causing query timeouts. A sudden spike in this counter, especially if accompanied by syslog 410002 (rate-limited ID mismatch warnings), may indicate a DNS cache poisoning attack and warrants investigation of the source addresses. To reduce false positives from legitimate timeout scenarios, you can disable dns-guard in the DNS inspection policy-map if transaction ID validation is not required for your security posture. If the drops are impacting legitimate traffic, verify that DNS servers are responding promptly and that network paths are stable. Contact Cisco TAC if you observe persistent drops affecting production DNS resolution.

Syslogs:

410002 (severity 2): Logged when the rate of ID mismatches exceeds the threshold configured by the id-mismatch command in the DNS inspection policy-map.

----------------------------------------------------------------

inspect-dns-invalid-domain-label

DNS Inspect invalid domain label

The firewall dropped a DNS packet because a domain name or label within the packet violates RFC 1035 length constraints. RFC 1035 specifies that individual DNS labels (the segments between dots in a domain name) must not exceed 63 bytes, and the complete domain name must not exceed 255 bytes. This validation occurs when DNS inspection with protocol-enforcement is enabled (the default configuration). The counter increments for both legitimately malformed DNS traffic and, in some scenarios, non-DNS traffic that was incorrectly matched by the inspection policy. Common triggers include DNS responses undergoing NAT translation where label rewriting causes length violations, DNS queries with excessively long labels or domain names, and UDP traffic on port 53 or 443 that resembles DNS but contains non-compliant data structures.

Recommendation:

First, verify whether the dropped traffic is actually DNS by examining packet captures or connection logs. If legitimate DNS traffic is being dropped, check whether the DNS server or client is generating non-compliant domain names that exceed RFC 1035 limits. If the domain names are intentionally long or non-standard, disable protocol-enforcement in the DNS inspection policy-map using 'policy-map type inspect dns <name>' followed by 'parameters' and 'no protocol-enforcement'. If non-DNS traffic (such as Citrix EDT, VPN protocols, or other UDP applications) is being incorrectly inspected as DNS, refine the class-map to match DNS traffic more precisely rather than relying on default-inspection-traffic, or exclude the specific ports from DNS inspection. For environments using Umbrella DNS integration, ensure you are running a software version that correctly handles the interaction between DNS inspection and Umbrella features. If drops persist after configuration adjustments and impact production traffic, contact Cisco TAC with packet captures and the output of 'show service-policy' and 'show asp drop'.

Syslogs:

410001

----------------------------------------------------------------

inspect-dns-invalid-pak

DNS Inspection Invalid Packet

The appliance dropped a DNS packet because DNS inspection detected a fundamental protocol violation that prevents safe parsing. This occurs when the DNS packet structure is malformed in ways that make it impossible to process: the packet is too short to contain a complete DNS header (less than 12 bytes), the DNS header indicates data sections that extend beyond the actual packet boundary, or the packet contains zero-length DNS payload on port 53. These conditions indicate either network corruption, fragmentation issues, or potentially malicious traffic attempting to exploit parsing vulnerabilities. This counter applies only to UDP DNS traffic; TCP DNS packets are handled separately by the control plane when TCP DNS inspection is enabled. The drop protects the inspection engine from attempting to parse invalid memory regions.

Recommendation:

This drop typically indicates malformed DNS traffic reaching the appliance. First, verify whether the drops correlate with legitimate DNS failures by checking if DNS resolution is working for clients. If DNS is functioning normally, these drops likely represent background noise from scanning tools, malformed queries from misconfigured clients, or network corruption. Use packet capture to examine the dropped traffic and identify the source. If drops are frequent and affecting legitimate DNS traffic, check for: MTU mismatches causing fragmentation of DNS packets, network devices corrupting DNS traffic in transit, or DNS clients sending malformed queries. If the source is a specific DNS server or client, investigate that system's DNS implementation. For isolated occurrences or drops from untrusted networks, no action is required—the appliance is correctly rejecting invalid protocol traffic. Contact Cisco TAC if legitimate DNS traffic is being dropped and packet captures show properly formatted DNS messages.

Syslogs:

None

----------------------------------------------------------------

inspect-dns-opt-format-error

DNS Inspection: Multiple OPT Records Detected

This counter increments when DNS inspection detects a DNS message containing more than one OPT pseudo-record. OPT records are part of the Extension Mechanisms for DNS (EDNS) defined in RFC 6891, which allows DNS clients and servers to advertise larger message sizes, DNSSEC support, and other extended capabilities. The DNS protocol specification explicitly requires that at most one OPT record may appear in a DNS message, and it must be placed in the additional data section. When a DNS packet violates this requirement by including multiple OPT records, the firewall treats it as a malformed or potentially malicious message and drops it. This behavior protects against protocol violations and possible evasion attempts that exploit non-standard DNS message structures. The drop applies to both DNS queries and responses traversing the firewall when DNS inspection is enabled.

Recommendation:

This drop typically indicates one of the following conditions: (1) A misconfigured DNS client or server that incorrectly generates multiple OPT records in violation of RFC 6891, (2) Corrupted DNS traffic due to network issues or middlebox interference, or (3) A deliberate protocol violation attempt, possibly for reconnaissance or evasion purposes. To troubleshoot: Capture the dropped DNS packets using packet capture on the affected interface and examine the additional records section to confirm the presence of multiple OPT (type 41) records. Identify the source of the malformed traffic—if it originates from internal DNS infrastructure, review the DNS server or resolver configuration for EDNS compliance. If the traffic comes from external sources, the drops are protective and expected. In rare cases where a legitimate but non-compliant DNS implementation cannot be corrected, you may need to disable DNS inspection for specific flows using a class-map and policy-map configuration, though this reduces security visibility. Contact Cisco TAC if you observe this counter incrementing frequently from trusted DNS infrastructure, as it may indicate a software defect in the DNS implementation.

Syslogs:

None.

----------------------------------------------------------------

inspect-dns-out-of-app-id

DNS Inspection Transaction Tracking Memory Exhausted

This counter increments when DNS inspection cannot allocate memory to track a DNS message identifier (transaction ID). DNS inspection maintains a per-flow table of outstanding DNS queries to match responses, validate transaction IDs, and support features like DNS Guard, ID mismatch detection, ID randomization, and Cisco Umbrella integration. Each DNS query requires a small tracking structure to store the message ID and associated metadata. When the system cannot allocate this structure—typically due to memory pressure or exhaustion of the per-core inspection cache—the DNS packet is dropped and this counter increments. This affects both standard DNS inspection and Umbrella cloud-based DNS security when enabled. The drop occurs during query processing before the DNS message is fully inspected.

Recommendation:

Check overall system memory utilization with 'show memory' and 'show memory detail'. If memory usage is consistently high (above 80-85%), identify the largest consumers and consider reducing connection limits, disabling unused inspection engines, or upgrading to a platform with more memory. Review DNS inspection configuration with 'show service-policy inspect dns' to confirm which features are enabled—DNS Guard, ID randomization, and Umbrella integration all require transaction tracking. If DNS traffic volume is very high, consider whether all DNS flows require deep inspection or if a subset can be excluded via class-maps. In rare cases, this may indicate a memory leak; check for known defects in your software version (e.g., CSCvg07197 addressed high memory usage with certain inspection combinations). If the counter increments sporadically under normal memory conditions, collect 'show tech-support' and contact Cisco TAC, as this may indicate cache exhaustion or a transient allocation failure.

Syslogs:

None.

----------------------------------------------------------------

inspect-dns-pak-too-long

DNS message exceeds configured maximum length

This counter increments when a DNS query or response exceeds the maximum message size configured in the DNS inspection policy. By default, DNS inspection enforces a 512-byte limit on all DNS messages, which aligns with the original RFC 1035 specification for UDP DNS. However, modern DNS features such as DNSSEC and EDNS0 (Extension Mechanisms for DNS) often produce responses larger than 512 bytes. The counter can increment for three distinct checks: the general maximum message length (applies to both queries and responses), the maximum client length (applies only to responses, based on the buffer size advertised by the client in the query), and the maximum server length (applies only to queries from servers). When both general and client-specific limits are configured, the client limit takes precedence for response validation. This drop is most commonly seen in environments using DNSSEC-signed zones, large TXT records, or EDNS0-enabled resolvers where legitimate DNS traffic exceeds the default 512-byte threshold.

Recommendation:

Review your DNS traffic requirements. If you are using DNSSEC, EDNS0, or other modern DNS features that require larger message sizes, you have several options: (1) Increase the maximum message length in your DNS inspection policy map using the 'message-length maximum' command with a higher byte value (common values are 1280 or 4096 bytes). (2) Remove the length restriction entirely by using 'no message-length maximum' in the DNS inspection policy map parameters. (3) For response-only adjustments, configure 'message-length client' to allow larger responses based on client capabilities. If the drops are infrequent and involve non-critical queries, the default 512-byte limit may be acceptable. To modify the default policy, create a custom DNS inspection policy map and apply it to your service policy. Verify that legitimate DNS resolution is not being impacted by checking for failed lookups or timeouts coinciding with these drops.

Syslogs:

410001

----------------------------------------------------------------

inspect-dns-umbrella-appid-fail

Umbrella DNS transaction tracking failure

The device dropped a DNS packet because it could not track the transaction state required for Cisco Umbrella DNS integration. This occurs only when Umbrella DNS connector is configured with DNS inspection enabled. The device maintains a transaction table that maps original DNS query IDs to Umbrella-modified query IDs, allowing responses from Umbrella to be correlated back to the original client. This counter increments in two situations: (1) when processing a client DNS query destined for Umbrella, the device failed to create a new transaction entry, typically due to memory exhaustion or transaction table capacity limits; (2) when processing a DNS response from Umbrella, the device could not find the corresponding transaction entry, usually because the original query timed out (default 10-second timeout) or the entry was never successfully created. High DNS query rates, memory pressure, or delayed responses from Umbrella resolvers increase the likelihood of this drop.

Recommendation:

Check system memory usage with 'show memory' and 'show blocks' to identify memory exhaustion. Review DNS traffic volume with 'show service-policy' and 'show conn' to determine if query rates exceed device capacity. Examine 'show asp table classify' for DNS flows and verify Umbrella resolver reachability. If drops occur during high DNS query bursts, consider rate-limiting DNS traffic or increasing device memory. Check for delayed responses from Umbrella resolvers (208.67.220.220, 208.67.222.222) using packet captures. If clients are configured to query Umbrella resolver IPs directly rather than using the device as DNS proxy, upgrade to version 9.12.1 or later to resolve a known issue (CSCvm68082). For persistent drops under normal load, collect 'show tech-support' and contact Cisco TAC, as this may indicate a resource exhaustion condition requiring configuration tuning or hardware upgrade.

Syslogs:

None.

----------------------------------------------------------------

inspect-dns-umbrella-flow-exp

DNS response from Umbrella dropped because client flow expired

This counter increments when the firewall receives a DNS response from the Cisco Umbrella cloud resolver but cannot deliver it because the original client connection has already closed or timed out. When DNS inspection with Umbrella integration is enabled, the firewall forwards client DNS queries to Umbrella resolvers for security analysis, storing transaction state to match responses back to the original client. The firewall maintains this transaction mapping for up to 10 seconds. If the Umbrella response arrives after the client flow has been removed—due to the client closing the connection, an idle timeout, or network delays exceeding the client's retry interval—the response cannot be delivered and is dropped. This typically occurs when clients have aggressive DNS timeout settings (shorter than the round-trip time to Umbrella plus processing delay), when network latency to Umbrella resolvers is high, or when clients cancel queries before receiving responses. The counter may also increment during periods of network congestion or when Umbrella resolver response times are elevated.

Recommendation:

Review the counter rate and context. Occasional increments are normal when clients retry DNS queries or close connections before responses arrive. Sustained high rates suggest one of these conditions: (1) Network latency to Umbrella resolvers is excessive—verify reachability and round-trip time to the configured Umbrella resolver addresses using ping or traceroute; check for routing issues or WAN congestion. (2) Client DNS timeout settings are too aggressive—if clients are configured with very short DNS timeouts (less than 2-3 seconds), they may abandon queries before Umbrella can respond; consider adjusting client resolver timeout settings if feasible. (3) Flow idle timeouts are too short—review the timeout configuration for UDP flows to ensure they accommodate typical DNS query/response cycles. (4) Umbrella service delays—if Umbrella is experiencing elevated response times, consider checking Umbrella service status or reviewing fail-open configuration to allow local DNS resolution during Umbrella outages. Use packet captures on both client-facing and Umbrella-facing interfaces to measure actual round-trip times and identify whether delays occur in the network path or at the Umbrella service. If the counter increments frequently and DNS resolution is failing for clients, verify Umbrella resolver reachability and consider enabling fail-open mode to prevent DNS outages during connectivity issues.

Syslogs:

None

----------------------------------------------------------------

inspect-dns-umbrella-no-memory

Umbrella DNS inspection packet buffer allocation failure

This counter increments when the firewall cannot allocate memory to process a DNS query through Cisco Umbrella integration. When Umbrella DNS security is enabled in a DNS inspection policy, the firewall modifies each outbound DNS query by adding EDNS0 extension fields containing the device identifier and client IP address before forwarding the query to Umbrella resolvers. This modification requires extending the original DNS packet buffer by approximately 50-100 bytes. If the system cannot allocate the additional memory needed for this extension, the DNS query is dropped and this counter increments. This can occur during memory pressure from high connection rates, sustained traffic load, or when memory block pools are depleted. The drop affects only the specific DNS query that triggered the allocation failure; other traffic continues normally.

Recommendation:

Check overall system memory utilization with 'show memory' and data-plane memory block allocation with 'show blocks'. Look for block pools with high FAILED counts or LOW watermarks approaching zero, particularly for 1550-byte and 2048-byte blocks used for packet buffers. Review 'show asp drop' for other memory-related drops that may indicate broader resource exhaustion. If drops are frequent, consider: (1) reducing DNS query rate or connection load, (2) increasing system memory if the platform supports it, (3) temporarily disabling Umbrella integration to confirm it resolves the issue, or (4) reviewing whether DNS traffic patterns (such as very large queries with many EDNS0 options already present) are consuming excessive buffer space. Isolated occurrences during traffic spikes are typically benign and self-correcting. Sustained or frequent drops indicate insufficient memory resources for the current traffic profile and Umbrella feature combination. Contact Cisco TAC if drops persist after verifying adequate memory headroom.

Syslogs:

None

----------------------------------------------------------------

inspect-dp-out-of-memory

Inspect Datapath Out of Memory

This counter increments when the inspection datapath cannot allocate memory during TLS Server Identity Discovery (TSID) operations. TSID is used with SSL/TLS decryption policies to discover server certificates before establishing client connections. When TSID is enabled, the firewall initiates probe connections to TLS servers to retrieve and cache their certificates. This drop occurs specifically when the system fails to allocate memory to store the TLS ClientHello data from these probe connections. The failure typically happens during high connection rates when many TLS sessions are being established simultaneously, causing temporary resource exhaustion in the datapath memory pools used for TCP proxy operations. This is distinct from general system memory exhaustion and relates specifically to per-connection memory allocation within the inspection engine.

Recommendation:

Check if TLS Server Identity Discovery is enabled in your SSL decryption policy. If this counter is incrementing during periods of high TLS connection establishment rates, the system may be experiencing temporary datapath memory pool exhaustion. Monitor overall system memory with 'show memory' and check for block depletion with 'show blocks'. If the drops correlate with high connection rates and TSID is enabled, consider temporarily disabling TLS Server Identity Discovery to determine if it resolves the issue. If drops persist or system memory is critically low (below 10% free), investigate other memory consumers. For sustained high TLS connection rates with TSID enabled, ensure the platform has adequate memory resources for the traffic load. Contact Cisco TAC if drops continue after verifying memory availability, as this may indicate a resource scaling issue with the TSID feature under your specific traffic patterns.

Syslogs:

None

----------------------------------------------------------------

inspect-gtp

GTP inspection validation or policy drop

The firewall drops a GTP (GPRS Tunneling Protocol) packet when inspection detects a protocol violation, policy restriction, or internal processing error. This counter increments for multiple distinct conditions: malformed GTP messages (missing mandatory Information Elements, invalid header lengths, incorrect TEID values, unsupported message types), policy-based drops (APN filtering, message type restrictions, tunnel limit exceeded, IMSI filtering), protocol violations (GTP-in-GTP encapsulation, TCP transport instead of UDP, IP version translation scenarios), and resource exhaustion (GSN node allocation failures). The inspection engine validates GTP versions 0, 1, and 2 control plane signaling and user plane data packets against 3GPP specifications. Common triggers include mobile network equipment sending non-compliant Create PDP Context requests, Delete PDP Context responses with unexpected TEID values, Echo Request packets with unsupported Information Element types, or exceeding configured per-GSN tunnel limits. By default, the firewall drops all packets that fail validation; the 'permit-errors' policy-map parameter can override this to allow malformed packets through while still counting them.

Recommendation:

Check the accompanying syslog message 324001 which identifies the specific GTP message type, direction, and failure reason (e.g., 'Mandatory IE is missing', 'Invalid TEID', 'Header length too short'). Use 'show service-policy inspect gtp' to view per-GSN drop statistics and identify which mobile network nodes are sending problematic traffic. If drops occur for legitimate traffic due to vendor-specific GTP implementations that deviate from 3GPP standards, consider enabling 'permit-errors' under the GTP inspection policy-map to allow non-critical violations while maintaining visibility. For specific known issues: verify software version includes fixes for IE type 152 validation (CSCwi43782), Delete PDP Context Response TEID=0 handling (CSCwf75694), and mandatory IE validation for Modify Bearer Command messages (CSCwm90900). Capture dropped packets with 'capture <name> type asp-drop inspect-gtp' and analyze with Wireshark to identify the exact protocol deviation. If drops persist after validation, engage TAC with packet captures, the full syslog message, and output from 'show service-policy inspect gtp detail'.

Syslogs:

324001

----------------------------------------------------------------

inspect-icmp-bad-code

Invalid ICMP Echo Code

The firewall dropped an ICMP echo request or echo reply packet because the ICMP code field was non-zero. According to RFC 792 (ICMPv4) and RFC 4443 (ICMPv6), echo request and echo reply messages must always use code 0; any other value violates the protocol specification. This counter increments only when stateful ICMP inspection is enabled. Non-zero codes in echo packets may indicate malformed traffic from misconfigured devices, buggy network stacks, or deliberate crafting by an attacker attempting to bypass inspection or exploit vulnerabilities. This drop was added as a security hardening measure to prevent attackers from using malformed ICMP packets to evade stateful inspection.

Recommendation:

Occasional drops are typically benign and may result from broken network equipment or non-compliant ICMP implementations. If drops are persistent or high-volume from specific sources, investigate the sending device for misconfiguration or compromise. Review the associated syslog 313009 messages to identify the source addresses and ICMP types involved. If the traffic is from a known-legitimate but non-compliant device that cannot be fixed, you can disable ICMP inspection on the affected interface using 'no inspect icmp', though this reduces security by removing stateful tracking. If drops correlate with suspected attack activity, consider blocking the source hosts with access control lists.

Syslogs:

313009

----------------------------------------------------------------

inspect-icmp-error-different-embedded-conn

ICMP Error Inspection - Embedded Connection Mismatch

This counter increments when an ICMP error message arrives and the original packet information embedded within the ICMP payload does not match the connection that was established when the ICMP error flow was first created. This is a strict validation check that occurs during ICMP error inspection. The most common scenario is a timing issue: when multiple ICMP error messages (such as from traceroute or Path MTU Discovery) arrive simultaneously from the same upstream router with identical outer IP headers but different embedded payloads, they are classified to the same flow. The first packet creates the flow and records its embedded payload; subsequent packets with different embedded information are dropped because they do not match the recorded payload. This validation prevents ICMP error messages from being forwarded to the wrong recipient, which is particularly important when application inspection or service modules are involved. For example, a Path MTU Discovery packet should be diverted to a service module while a traceroute response should not. If the ICMP error messages arrived with even a small time interval between them, the first flow would be torn down before the second arrives, allowing each to create its own flow successfully.

Recommendation:

This drop is typically benign and indicates correct security enforcement. It commonly occurs during network troubleshooting when tools like traceroute send multiple probes rapidly, or when Path MTU Discovery and other ICMP error types arrive simultaneously. Review the Original IP Payload information in syslog 313005 to verify the embedded connection details. If drops are frequent and impacting legitimate traffic, check whether upstream routers are sending bursts of ICMP error messages. In most cases, the dropped packets are redundant or duplicate error notifications. If you suspect malicious activity (such as ICMP error spoofing or flooding), use access control lists to rate-limit or block the source. Contact Cisco TAC only if legitimate ICMP error messages (such as Path MTU Discovery) are being consistently dropped and causing application failures.

Syslogs:

313005

----------------------------------------------------------------

inspect-icmp-error-nat64-error

ICMP Error Message NAT64/NAT46 Translation Failed

The device dropped an ICMP error message because it could not be translated between IPv4 and IPv6 formats. This occurs in NAT64 or NAT46 deployments when an ICMP error message (such as Destination Unreachable, Time Exceeded, Packet Too Big, or Parameter Problem) contains a type and code combination that is not supported for translation according to RFC 6145. The device enforces strict protocol compliance and only translates ICMP error messages that have defined mappings between IPv4 and IPv6. For example, certain ICMPv4 Destination Unreachable codes (like Host Precedence Violation) have no ICMPv6 equivalent and will be dropped. Similarly, unsupported ICMPv6 error types or codes that cannot be mapped to ICMPv4 will trigger this counter. This drop protects against malformed or non-standard ICMP error messages that could cause translation ambiguity or protocol violations.

Recommendation:

Review the syslog message 313005 to identify the source and type of ICMP error message being dropped. Check the embedded original packet information in the syslog to determine which ICMP type and code combination triggered the drop. If the drops are infrequent and from untrusted sources, no action is required—the device is correctly enforcing RFC 6145 compliance. If legitimate ICMP error messages from trusted network devices (such as routers generating Time Exceeded for traceroute) are being dropped, verify that your NAT64/NAT46 configuration is correct and that the ICMP error types being generated are standard and supported. If the counter increments rapidly or from a specific source, investigate whether the source is generating non-standard ICMP error messages or if this represents an attack attempt. In that case, use access control lists to block the offending source. Contact Cisco TAC if legitimate ICMP error messages that should be translatable are being dropped.

Syslogs:

313005

----------------------------------------------------------------

inspect-icmp-error-no-existing-conn

ICMP Error Inspection: No Matching Connection Found

This counter increments when the firewall receives an ICMP error message (such as Destination Unreachable, Time Exceeded, or Parameter Problem) but cannot locate an active connection that matches the original packet embedded inside the ICMP error payload. ICMP error messages contain a copy of the IP header and first bytes of the original packet that triggered the error. The firewall extracts this embedded packet information and searches its connection table for the corresponding session. If no matching connection exists—because the original connection has already timed out, was never established through the firewall, or the embedded packet information does not match any known flow—the ICMP error is dropped. This behavior is expected when ICMP errors arrive late (after the original connection has closed), when intermediate routers generate errors for traffic that did not originate through the firewall, or when the embedded packet has been altered in transit. The counter also increments if the firewall cannot acquire the connection lock for the embedded flow, or if the matched connection is a cluster stub flow that should have been redirected to the owning unit earlier in processing. When NAT is configured, the firewall must successfully translate the embedded packet addresses to match the connection table entries; translation failures also trigger this drop.

Recommendation:

Review the syslog message 313005 to identify the source and embedded packet details. Verify whether the ICMP errors correspond to legitimate traffic that recently passed through the firewall—if the original connections have already closed due to normal timeout or completion, these drops are expected and benign. Check connection timeout values if errors consistently arrive after connections expire. If the embedded packet information does not match any traffic handled by the firewall, the errors may be from external routers responding to traffic that bypassed the firewall or was spoofed. In environments with NAT, ensure that the 'inspect icmp error' policy is configured if you need the firewall to translate addresses in ICMP error payloads for proper end-to-end error delivery. Occasional increments are normal; sustained high rates may indicate network path issues, asymmetric routing, or an attack attempting to inject spoofed ICMP errors. If drops occur in a cluster deployment, verify that cluster director load balancing is functioning correctly to avoid stub flow lookups. Contact Cisco TAC if legitimate ICMP errors required for path MTU discovery or traceroute are being dropped unexpectedly.

Syslogs:

313005

----------------------------------------------------------------

inspect-icmp-invalid-pak

ICMP Inspect invalid packet

The appliance dropped an ICMP or ICMPv6 packet that failed validation during ICMP inspection. This counter increments only when ICMP inspection is enabled (via 'inspect icmp' in a service policy). The appliance performs two primary checks: (1) verifying the packet contains a complete ICMP header (minimum 8 bytes), and (2) for ICMPv6 Neighbor Solicitation messages, confirming the hop limit is exactly 255 as required by RFC 4861 to prevent off-link spoofing attacks. Common causes include truncated packets from network issues or transmission errors, malformed packets from misconfigured devices or protocol implementations, and malicious traffic such as reconnaissance scans or DoS attacks using crafted ICMP packets. This drop is a security enforcement when inspection detects packets that violate protocol specifications.

Recommendation:

If drops are intermittent and low-volume, no action is required—the appliance is correctly rejecting malformed traffic. If drops are frequent or impacting legitimate traffic: (1) Identify the source using packet captures or connection logs to determine if the traffic is from a trusted device or external source. (2) For ICMPv6 Neighbor Solicitation drops, verify that IPv6-enabled devices on the local network are sending standards-compliant packets with hop limit 255. (3) If the source is a misconfigured or legacy device that cannot be fixed, consider disabling ICMP inspection for that specific traffic class, though this reduces security visibility. (4) If drops correlate with suspected attack traffic, use access control lists to block the source addresses. (5) For persistent issues with legitimate traffic, collect packet captures showing the dropped ICMP packets and contact Cisco TAC to analyze whether the validation is too strict for your environment.

Syslogs:

None.

----------------------------------------------------------------

inspect-icmp-nat64-frag

Fragmented ICMP Packet Dropped During NAT64/NAT46 Translation

The device dropped a fragmented ICMP packet that required translation between IPv4 and IPv6 address families. This occurs when NAT64 (IPv6-to-IPv4) or NAT46 (IPv4-to-IPv6) translation is configured and the device receives an ICMP packet that has been fragmented at the IP layer. RFC 6145 explicitly prohibits translation of fragmented ICMP packets because the embedded payload in ICMP error messages cannot be reliably translated when split across fragments. This counter increments during ICMP inspection when both conditions are met: the flow requires address family translation (NAT64 or NAT46) and the packet is an IP fragment. The drop is a protocol compliance measure, not a malfunction.

Recommendation:

This is expected behavior and typically requires no action. Fragmented ICMP packets cannot be translated between IPv4 and IPv6 per protocol standards. If you see frequent drops, investigate the source of fragmented ICMP traffic: check for MTU mismatches on upstream paths, Path MTU Discovery issues, or devices generating unusually large ICMP messages. If legitimate ICMP error messages are being lost, address the fragmentation at the source by ensuring proper MTU configuration throughout the network path. The accompanying syslog message 313005 provides details about the dropped packet. This counter should remain low in normal operation; sustained high values may indicate a network configuration issue or an attempt to bypass translation by fragmenting ICMP packets.

Syslogs:

313005

----------------------------------------------------------------

inspect-icmp-out-of-app-id

ICMP Inspection Out of App ID

This counter increments when ICMP inspection is enabled and the device cannot allocate a tracking structure for an ICMP echo request. The device tracks the sequence number of each outbound echo request to validate the corresponding echo reply. Allocation can fail due to memory exhaustion in the per-core cache or when the connection lock cannot be acquired. This drop only occurs when 'inspect icmp' is configured in a service policy applied to the traffic.

Recommendation:

Check system memory usage with 'show memory' and 'show blocks'. If memory is low, investigate what is consuming memory (connections, NAT translations, inspection sessions). If memory is adequate, the drops may indicate transient lock contention under high ICMP traffic volume. Review the ICMP inspection configuration—if ICMP inspection is not required for your security policy, consider removing 'inspect icmp' from the service policy. If drops persist with adequate memory, contact Cisco TAC with the output of 'show tech-support' and 'show asp drop' history.

Syslogs:

None

----------------------------------------------------------------

inspect-icmp-seq-num-not-matched

ICMP echo reply sequence number not matched

The appliance dropped an incoming echo reply because its sequence number does not match any echo request that was previously tracked on the same connection. When stateful ICMP inspection is enabled, the appliance maintains a table of sequence numbers from outbound echo requests and validates that each inbound echo reply corresponds to a legitimate request. This security check prevents unsolicited or spoofed echo replies from entering the network. The counter increments when a reply arrives with an unrecognized sequence number, which can occur if the original request was never sent through the appliance, the request timed out and was removed from the tracking table, or the reply arrived after the connection was already torn down. In high-throughput scenarios or VPN environments with rapid back-to-back echo traffic, timing conditions may cause legitimate replies to be dropped when flows are reused or terminated before all replies are received.

Recommendation:

If drops are occasional, no action is required—this is normal security enforcement blocking unsolicited replies. If drops are frequent or affecting legitimate traffic, verify that echo requests are actually traversing the appliance before replies arrive. In environments with high-rate ICMP monitoring (such as synthetic monitoring tools sending rapid probes), consider reducing the probe rate or disabling ICMP inspection if access control lists provide sufficient security. For VPN tunnel scenarios experiencing consistent drops, check for known issues in your software version related to rapid ICMP traffic over encrypted tunnels. If the source is untrusted and drops persist, the traffic may be malicious—use access control lists to explicitly deny the source host. Review the associated syslog message for source and destination details to determine whether the traffic is expected.

Syslogs:

313004

----------------------------------------------------------------

inspect-icmpv6-error-invalid-pak

ICMPv6 Error Message Contains Malformed Embedded Packet

This counter increments when the appliance receives an ICMPv6 error message (such as Destination Unreachable, Time Exceeded, Packet Too Big, or Parameter Problem) that contains a malformed IPv6 packet in its payload. ICMPv6 error messages include a copy of the original IPv6 packet that triggered the error, and the appliance inspects this embedded packet to correlate it with existing connections and perform address translation if needed. The drop occurs when the embedded IPv6 packet fails validation checks, including: incomplete or truncated IPv6 header (less than 40 bytes available), malformed IPv6 extension headers (hop-by-hop options, destination options, routing, fragment, or authentication headers with invalid lengths or structure), extension header chain that exceeds the available packet length, unsupported or invalid Next Header values, or fragment headers with inconsistent offset information. This validation protects against maliciously crafted ICMPv6 error messages that could be used to disrupt connections or exploit parsing vulnerabilities. The counter may increment during network attacks involving spoofed ICMPv6 errors, when intermediate routers or hosts generate malformed ICMPv6 errors due to software bugs, or when IPv6 extension header chains are corrupted in transit.

Recommendation:

This drop is a security feature and typically indicates either a network attack or a malfunctioning IPv6 device generating invalid ICMPv6 error messages. Review the source addresses of dropped ICMPv6 error packets using packet captures to identify the origin. If the source is an internal router or firewall, check for software updates or configuration issues on that device. If the source is external or untrusted, the drops are expected and protect your network from malformed packets. Sustained high rates of this counter from a specific source may indicate an attack attempt and should be investigated. No configuration change is required on the appliance itself—the validation is automatic and cannot be disabled. If legitimate ICMPv6 error messages are being dropped, the issue lies with the device generating the malformed errors, not with the appliance performing the inspection.

Syslogs:

None.

----------------------------------------------------------------

inspect-icmpv6-error-no-existing-conn

ICMPv6 error message with no matching connection

The firewall received an ICMPv6 error message (such as Destination Unreachable, Time Exceeded, or Packet Too Big) but could not correlate it to any active connection. ICMPv6 error messages contain a portion of the original packet that triggered the error; the firewall extracts this embedded packet and searches for the corresponding connection in its state table. This counter increments when no match is found. Common causes include: the original connection has already timed out or closed before the error arrived; the error message was delayed in transit; the error references traffic the firewall never tracked (asymmetric routing); or the ICMPv6 error is spoofed or unsolicited. This behavior is expected in environments with connection timeouts, network delays, or when external devices send error messages for flows not passing through the firewall.

Recommendation:

Review the syslog message 313005 to identify the source of the ICMPv6 error messages and examine the embedded packet details. If the drops are occasional and correlate with legitimate connection timeouts or network path changes, no action is required—this is normal behavior. If the counter increments frequently from specific sources, investigate whether those hosts are misconfigured or experiencing routing issues. Persistent drops from untrusted sources may indicate reconnaissance or spoofing attempts; consider using access control lists to block the offending hosts. Check for asymmetric routing scenarios where return traffic or ICMP errors traverse the firewall but the original flows do not. If legitimate ICMPv6 error messages (such as Path MTU Discovery) are being dropped and causing application issues, verify that the original connections are being tracked properly and have not prematurely timed out.

Syslogs:

313005

----------------------------------------------------------------

inspect-rtcp-invalid-length

RTCP Packet Length Too Short

This counter increments when RTCP conformance inspection detects a UDP packet with insufficient length to contain a valid RTCP header. The firewall drops the packet when the UDP payload length is smaller than the minimum RTCP header size (8 bytes). This validation occurs only when RTCP conformance checking is enabled in the inspection policy for VoIP protocols (SIP, H.323, or Skinny/SCCP). The drop protects dynamically opened media pinholes from malformed or malicious RTCP traffic. Common causes include corrupted packets, misconfigured media endpoints, or attackers attempting to exploit VoIP media channels with undersized packets.

Recommendation:

Verify that legitimate RTCP traffic is not being dropped by capturing packets on both sides of the firewall and examining the UDP length field. If the source is a known media endpoint, check for firmware issues or network corruption between the endpoint and the firewall. If drops are frequent and from untrusted sources, this is expected security behavior and no action is required. To temporarily bypass this check for troubleshooting, disable RTCP conformance in the inspection policy using 'no rtp-conformance enforce-payloadtype' under the relevant inspection class. If legitimate traffic is consistently malformed, contact the media endpoint vendor. For persistent issues with known-good endpoints, collect packet captures and contact Cisco TAC.

Syslogs:

None.

----------------------------------------------------------------

inspect-rtcp-invalid-payload-type

Invalid RTCP Payload Type

The firewall dropped an RTCP (Real-Time Control Protocol) packet because its payload type field contained a value outside the ranges defined by RFC 3550 (formerly RFC 1889). Valid RTCP payload types are 200 (Sender Report), 201 (Receiver Report), 202 (Source Description), 203 (BYE), and 204 (Application-Defined), plus a few extended types for specific feedback mechanisms. This counter increments when RTCP inspection is enabled and detects packets with non-standard or malformed payload type values. RTCP inspection is automatically applied to control traffic for voice and video sessions negotiated through SIP, H.323, MGCP, or Skinny (SCCP) protocols. The drop protects against malformed media streams, protocol violations, or potential evasion attempts using invalid RTCP packet types.

Recommendation:

Investigate the media source (IP phone, video endpoint, SIP trunk, or media gateway) sending the non-compliant RTCP traffic. Check whether the device firmware is current and whether it is configured to use standard RTCP packet types. Review the syslog message 431002 to identify the source and destination of the dropped packets, including the specific invalid payload type value. If the traffic is from a known-good endpoint that uses proprietary or extended RTCP packet types not covered by the standard, you may need to disable RTCP conformance checking for that traffic flow using the 'no rtp-conformance' command within the appropriate inspection policy map. However, disabling conformance checking reduces security visibility. If drops are widespread across multiple endpoints or affect production voice/video quality, verify that inspection policies are correctly applied and that NAT is not corrupting RTCP headers. Contact TAC if legitimate RTCP traffic from standards-compliant endpoints is being dropped.

Syslogs:

431002

----------------------------------------------------------------

inspect-rtcp-invalid-version

Invalid RTCP Version Field

This counter increments when an RTCP (RTP Control Protocol) packet is received with a version field other than 2, the only valid version defined in RFC 3550. RTCP inspection occurs when the 'rtp-conformance' feature is enabled within H.323, SIP, or Skinny (SCCP) inspection policy maps. The firewall validates the 2-bit version field in the RTCP header and drops packets that do not conform to the standard. This drop typically indicates one of three conditions: a misconfigured or non-compliant VoIP endpoint, corrupted packets in transit, or potentially malicious traffic attempting to exploit VoIP pinholes. The dropped packet's source address and the invalid version value are logged in syslog message 431002.

Recommendation:

Review syslog 431002 messages to identify the source IP address and the invalid version value received. Verify that all VoIP endpoints (IP phones, media gateways, video conferencing systems) in your network are using RFC 3550-compliant RTCP implementations. If the drops are from a specific device, check for firmware updates or configuration issues on that endpoint. If drops occur sporadically from multiple sources, investigate potential network issues causing packet corruption. If the traffic is from an untrusted source or the version values appear random, this may indicate scanning or attack activity—consider blocking the source with an ACL. If you have legacy VoIP equipment that cannot be upgraded and requires non-standard RTCP versions, you may need to disable RTP conformance checking for that traffic class, though this reduces security. Contact TAC if legitimate VoIP traffic is being dropped and the source devices are known to be compliant.

Syslogs:

431002

----------------------------------------------------------------

inspect-rtp-invalid-length

Invalid RTP Packet Length

The packet was dropped because the UDP payload length is smaller than the minimum RTP header size (12 bytes). This occurs when RTP or SRTP inspection is enabled and detects a malformed or truncated packet that cannot contain a valid RTP header. Common causes include misconfigured or buggy VoIP endpoints sending malformed packets, network-induced packet truncation, or non-RTP traffic incorrectly classified as RTP/SRTP media. This counter typically indicates a problem with the sending device rather than the firewall configuration.

Recommendation:

Use packet capture to identify the source IP address and port sending the malformed packets. Investigate the VoIP endpoint or media gateway for configuration issues or software bugs. If the source is a known problematic device, you can block it using an access control list. If legitimate RTP traffic is being dropped, verify that RTP/SRTP inspection policy-map parameters are appropriate for your environment, or consider disabling RTP inspection if it is not required for your security policy. Check for the accompanying syslog message %ASA-4-431001 which provides additional details about the dropped RTP packet including source and destination addresses.

Syslogs:

%ASA-4-431001

----------------------------------------------------------------

inspect-rtp-invalid-payload-type

RTP payload type does not match negotiated media type

This counter increments when RTP inspection detects a mismatch between the payload type in an RTP packet header and the media type (audio or video) negotiated during SIP call setup. The firewall tracks the expected media type for each RTP flow based on the SIP signaling exchange. Audio flows expect payload types 0-34 or 96-127 (dynamic range), while video flows expect a different set of payload types plus the dynamic range 96-127. When a packet arrives with a payload type that does not match the negotiated media category, the packet is dropped and syslog 431001 is generated. This enforcement only occurs when RTP conformance checking is enabled in the SIP inspection policy-map (via the 'rtp-conformance' or 'enforce-payloadtype' parameters). Common scenarios include: misconfigured endpoints sending the wrong media type on a pinhole, mid-call media type changes during SIP re-invites that the firewall has not yet processed, or endpoints that violate the negotiated SDP media attributes.

Recommendation:

First, verify that RTP conformance is intentionally enabled in your SIP inspection policy-map; if strict payload type enforcement is not required for your environment, you can disable 'enforce-payloadtype' while keeping other RTP conformance checks active. If enforcement is desired, examine the syslog 431001 messages to identify the source endpoint and the specific payload type value being rejected. Compare the payload type against the SDP offer/answer in the SIP signaling (visible in 'capture' output with SIP inspection enabled) to determine whether the endpoint is violating the negotiated media type. If drops occur during mid-call re-invites or hold/resume operations, this may indicate a timing issue where RTP packets arrive before the firewall processes the updated SIP signaling; in such cases, consider whether the strict enforcement is necessary or if the application can tolerate brief media interruptions. If the endpoint is legitimately misconfigured and sending video on an audio channel (or vice versa), correct the endpoint configuration or use an ACL to block the misbehaving host if it cannot be fixed.

Syslogs:

431001

----------------------------------------------------------------

inspect-rtp-invalid-version

RTP Version Field Not Equal to 2

This counter increments when the device drops an RTP packet because the version field in the RTP header does not contain the value 2, which is the only valid version defined by RFC 3550 (and its predecessor RFC 1889). RTP conformance checking is triggered when you enable the 'rtp-conformance' command within the parameters of an H.323, SIP, or Skinny (SCCP) inspection policy map. When enabled, every RTP packet flowing through dynamically opened media pinholes is validated for protocol compliance. The version field occupies the first 2 bits of the RTP header; any value other than 2 (binary 10) causes the packet to be dropped and syslog 431001 to be generated. This drop typically indicates one of three conditions: non-RTP traffic is being sent on ports allocated for RTP media (for example, a misconfigured application sending arbitrary UDP data), a malformed or corrupted RTP implementation on an endpoint, or an attacker attempting to exploit the media pinhole with crafted packets.

Recommendation:

First, verify that RTP conformance checking is intentionally enabled in your VoIP inspection policy. If you do not require strict protocol validation, you can disable it by removing the 'rtp-conformance' command from the inspection policy-map parameters for the affected protocol (H.323, SIP, or Skinny). If conformance checking is required, identify the source IP address from the syslog 431001 message and investigate the endpoint: confirm it is a legitimate VoIP device, check for firmware updates or known compatibility issues, and verify that no other application is using the dynamically allocated RTP port range. Capture the dropped packets to examine the actual version field value being sent. If the source is a known-good VoIP endpoint that cannot be corrected, you may need to disable RTP conformance for that call flow or use an access control list to permit the traffic outside of inspection. Contact Cisco TAC if legitimate RTP traffic from standards-compliant endpoints is being dropped.

Syslogs:

431001

----------------------------------------------------------------

inspect-rtp-max-outofseq-paks-probation

RTP source validation failed due to excessive out-of-sequence packets

This counter increments when RTP inspection drops packets from a new RTP source that has not yet been validated. When RTP conformance checking is enabled (configured via SIP, H.323, or Skinny inspection policies), each new RTP source must pass a probation period before the firewall accepts its traffic. During probation, the firewall requires 5 consecutive in-sequence packets to validate the source. If more than 20 out-of-sequence packets arrive during this probation period, the firewall considers the source invalid and drops subsequent packets. This protection prevents malformed or potentially malicious RTP streams from traversing dynamically opened media pinholes. The counter typically increments when network conditions cause significant packet reordering, when endpoints send RTP packets with non-sequential numbering during call setup, or when certain video conferencing systems generate RTP streams that do not conform to strict sequencing requirements during the initial packets of a session.

Recommendation:

Verify whether the RTP source is legitimate. If the drops affect production voice or video traffic, check for network issues causing packet reordering between the endpoint and the firewall (such as asymmetric routing, load balancing, or high jitter). Review the syslog message 431001 to identify the specific source IP and port experiencing validation failures. If legitimate endpoints consistently trigger this drop, and network conditions cannot be improved, consider disabling RTP conformance checking in the inspection policy for the affected traffic. Note that the 20-packet threshold during probation is not configurable. For troubleshooting, capture packets at both the source and the firewall to determine whether sequencing issues originate from the endpoint or occur in transit.

Syslogs:

431001

----------------------------------------------------------------

inspect-rtp-sequence-num-outofrange

RTP Sequence Number Out of Range

This counter increments when an audio or video media packet arrives with a sequence number that falls outside the acceptable tracking window during an active call. After the initial validation period for a new media stream (which requires 5 consecutive in-order packets), the inspection engine tracks sequence numbers to detect packet loss and reordering. Packets are dropped when the sequence number is a duplicate, arrives significantly out of order without corresponding packet loss, or represents a large forward jump that suggests a stream restart. This typically occurs during SIP-signaled voice or video calls when network conditions cause excessive jitter, packet reordering, or when media sources restart mid-call without proper signaling. The counter may also increment during NAT traversal issues or when packets take asymmetric paths through the network.

Recommendation:

Review network conditions between the media endpoints and the firewall. Check for packet loss, jitter, or reordering using packet captures or quality-of-service monitoring tools. If drops occur during call setup, verify that media packets arrive in sequence during the initial validation period. For ongoing calls, occasional drops may be benign if the media source recovers (the inspection engine will resynchronize after detecting consistent sequence numbers). If drops are frequent and affecting call quality, investigate upstream network issues, verify symmetric routing for media flows, and ensure media gateways are not restarting streams without proper SIP signaling. Consider disabling RTP inspection if it is not required for your security policy, as this validation adds processing overhead and may be unnecessary in trusted network segments.

Syslogs:

431001

----------------------------------------------------------------

inspect-rtp-ssrc-mismatch

RTP Synchronization Source Changed During Active Session

The firewall dropped an RTP media packet because the Synchronization Source (SSRC) identifier changed during an active session. RTP conformance inspection tracks the SSRC for each media flow and expects it to remain constant throughout the session. This counter increments when a packet arrives with a different SSRC than previously observed, and the timestamp difference indicates the change occurred too quickly to be a legitimate session restart. Common triggers include SIP re-invites (call hold/resume, mid-call codec changes), endpoint reboots during active calls, or potential security threats where an unauthorized host attempts to inject packets into an established media stream. This behavior is most often seen with Cisco TelePresence systems, music-on-hold scenarios, and certain SIP endpoints that change SSRC values during call modifications.

Recommendation:

Review the specific call scenario when drops occur. If drops coincide with legitimate call events (hold/resume, transfer, codec renegotiation), the SSRC change is expected behavior and RTP conformance is being too strict for your environment. Disable RTP conformance checking in your SIP inspection policy using 'policy-map type inspect sip' and removing the 'rtp-conformance' parameter under 'parameters'. If drops occur without corresponding call events, investigate whether an unauthorized device is attempting to send RTP packets on pinhole connections opened by the firewall—this could indicate a security issue. Check syslog message 431001 for the source and destination addresses to identify which endpoint is changing SSRC values. For environments with TelePresence, video conferencing systems, or complex SIP call flows, disabling rtp-conformance is often necessary to prevent legitimate media from being dropped.

Syslogs:

431001

----------------------------------------------------------------

inspect-scansafe-duplicate-conn

Cloud Web Security duplicate connection detected

This counter increments when the firewall attempts to redirect an HTTP or HTTPS connection to the Cloud Web Security (formerly ScanSafe) proxy server, but detects that another active connection already exists with the same source IP address and source port combination destined to the proxy. The firewall maintains a hash table of active proxy connections indexed by source IP and port to prevent connection overlap—a condition where two distinct client connections to different web servers would appear identical after redirection to the single proxy server IP. When a duplicate is detected, the new connection is dropped and syslog 775002 is generated. This protection prevents connection aliasing that would cause the proxy to mishandle traffic from multiple users or destinations. The condition most commonly occurs when extended (carrier-grade) PAT is configured alongside Cloud Web Security inspection, because extended PAT may assign the same translated source port to different client connections when they target different destination servers—but after Cloud Web Security redirection, all connections target the same proxy IP, creating a collision. It can also occur (rarely) if a client reuses the same ephemeral source port for multiple concurrent connections, or if the connection counter was not properly decremented after a previous connection failure (fixed in 9.1.7, 9.2.4, 9.4.2, and later).

Recommendation:

If this counter increments frequently, verify your NAT configuration. Extended PAT (configured with the 'extended' keyword in NAT rules) should not be used with Cloud Web Security inspection, as it can cause source port reuse across connections to different destinations. Use traditional PAT instead, which ensures unique source ports for each connection. If extended PAT is required for other traffic, apply Cloud Web Security inspection only to traffic that bypasses extended PAT, or use separate NAT policies. Occasional drops (one or two per day) may be benign, caused by rare client port reuse behavior. Persistent drops affecting multiple users indicate a NAT configuration issue. If the counter increments even without extended PAT and you are running a version older than 9.1.7, 9.2.4, or 9.4.2, upgrade to a fixed release—earlier versions had a defect (CSCut30741) where the connection counter was not decremented on registration failures, causing false duplicate detections. Review syslog 775002 messages to identify the affected source addresses and correlate with your NAT policy.

Syslogs:

775002

----------------------------------------------------------------

inspect-scansafe-encoding-failed

Cloud Web Security header encoding failed

This counter increments when the firewall cannot encode user or group identity information into the HTTP header during Cloud Web Security (formerly ScanSafe) redirection. When Cloud Web Security inspection is enabled with identity-aware policies, the firewall retrieves the username and group membership from either the Identity Firewall (IDFW) or AAA authentication database, then encodes this information into a special HTTP header (X-Scansafe) before redirecting the connection to the cloud service. If the encoding operation fails—typically due to invalid characters in the username or group name, or internal buffer constraints—the connection is dropped and this counter increments. The drop occurs during the initial HTTP request processing when the firewall attempts to insert identity metadata into the outbound request to the cloud proxy.

Recommendation:

Check the format of usernames and group names in your IDFW or AAA configuration. Ensure that usernames and group names do not contain characters that cannot be encoded (such as control characters or extremely long strings). Verify that the identity source (IDFW or AAA) is correctly configured and returning valid user information. If using Active Directory integration, confirm that domain\username and domain\\groupname syntax is correct. Review syslog message 775002 for the specific connection details and username that triggered the failure. If the issue persists with valid identity data, contact Cisco TAC with the output of 'show asp drop' and 'show logging | include 775002' to investigate potential software issues.

Syslogs:

775002

----------------------------------------------------------------

inspect-scansafe-hdr-encryption-failed

Cloud Web Security header encryption failed

The firewall dropped an HTTP or HTTPS connection because it could not encrypt the authentication header required for Cloud Web Security (formerly ScanSafe) proxy redirection. When Cloud Web Security inspection is enabled, the firewall intercepts client HTTP/HTTPS requests and injects encrypted authentication headers containing the license key, timestamp, and user identity before redirecting traffic to the cloud proxy. This counter increments when the encryption operation fails—typically due to cryptographic subsystem errors, insufficient memory, or internal buffer constraints during the header preparation process. The connection is terminated to prevent unprotected traffic from bypassing cloud security inspection.

Recommendation:

Verify that Cloud Web Security is properly configured with both a valid license key (configured under 'scansafe general-options') and the server public key. Check system memory and CPU utilization, as resource exhaustion can cause cryptographic operations to fail. Review the accompanying syslog message 775002 for the specific connection details. If the issue persists across multiple connections, disable and re-enable the Cloud Web Security configuration to reinitialize the cryptographic subsystem. If failures continue, collect a packet capture and troubleshooting bundle and contact Cisco TAC, as this may indicate a platform-specific cryptographic hardware or software issue.

Syslogs:

775002

----------------------------------------------------------------

inspect-scansafe-license-key-not-configured

Cloud Web Security license key not configured

This counter increments when traffic matches a policy configured for Cloud Web Security (formerly ScanSafe) inspection, but the required license key is missing from the configuration. Cloud Web Security redirects HTTP and HTTPS traffic to Cisco's cloud-based web security service for content scanning and malware protection. To authenticate with the cloud proxy servers, the security appliance must inject an encrypted authentication header into each web request, which requires a valid license key. Without this key, the appliance cannot construct the authentication header and must drop the connection. This typically occurs immediately after enabling Cloud Web Security inspection without completing the license configuration, or in multi-context deployments where a context is configured to use Cloud Web Security but lacks either a context-specific license or inheritance from the system context.

Recommendation:

Configure the Cloud Web Security license key using the 'license' command in scansafe general-options configuration mode. The license key is a 40-character hexadecimal string provided when you subscribe to Cisco Cloud Web Security. In single-context mode, configure the license globally. In multi-context mode, you can configure the license in the system context (inherited by all contexts) or configure context-specific licenses. Verify the configuration with 'show running-config scansafe' to confirm the license key is present. If the license key is configured but drops persist, verify that the key matches the subscription associated with your organization and that the Cloud Web Security proxy servers are reachable. If you are no longer using Cloud Web Security, remove the 'inspect scansafe' command from the affected service policy to stop redirecting traffic.

Syslogs:

775002

----------------------------------------------------------------

inspect-scansafe-max-conn-reached

Cloud Web Security maximum concurrent connections reached

This counter increments when a new HTTP or HTTPS connection matches a policy configured to redirect traffic to the Cloud Web Security (formerly Cisco ScanSafe) cloud proxy, but the platform has already reached its maximum number of concurrent redirected connections. Each platform model enforces a specific limit on how many simultaneous connections can be actively redirected to the cloud service for inspection. When this limit is reached, new connections that would otherwise be redirected are dropped instead. The connection is denied and syslog 775002 is generated showing the current platform limit.

Recommendation:

Check current Cloud Web Security connection usage with the command 'show scansafe statistics' and compare active session counts against your platform's documented maximum. If you are consistently hitting the limit, consider: (1) reviewing your Cloud Web Security policy to ensure only necessary traffic is being redirected, (2) distributing load across multiple devices if possible, or (3) upgrading to a higher-capacity platform. Note that versions prior to 9.1.7 / 9.2.4 / 9.4.2 contained a defect (CSCut30741) where this counter could increment incorrectly even when the limit was not reached; upgrade if you suspect false positives. If the limit seems appropriate for your traffic volume and the drops are infrequent, this may indicate temporary traffic bursts and could be normal behavior.

Syslogs:

775002

----------------------------------------------------------------

inspect-scansafe-public_key_not_configured

Cloud Web Security server encryption key not configured

This counter increments when HTTP or HTTPS traffic subject to Cloud Web Security (CWS, formerly ScanSafe) inspection cannot be redirected because the server encryption key required to secure authentication headers is missing. The security appliance drops the packet and closes the connection. This typically occurs in multi-context deployments when the 'scansafe' command has not been configured in a specific context, or when the 'scansafe server public-key' command has not been applied in older software versions. In modern releases, the encryption key is embedded in software and does not require manual configuration. The drop prevents unprotected traffic from bypassing cloud inspection when CWS policy is active.

Recommendation:

Verify that Cloud Web Security is properly configured for the affected context. In multi-context mode, ensure the 'scansafe' command (with optional license key) is configured within each context that requires CWS inspection, not just in the system execution space. Check that 'scansafe general-options' includes valid license and server configuration. If running software older than 8.5, verify that 'scansafe server public-key' points to a valid key file on flash storage. In current releases, the encryption key is built-in and this command is not required. Review the service policy to confirm CWS inspection is applied to the intended traffic classes. If the configuration is correct but drops persist, verify connectivity to the configured CWS proxy servers using 'show scansafe server' and check for related syslog 775002 messages that identify the affected connections.

Syslogs:

775002

----------------------------------------------------------------

inspect-scansafe-server-not-reachable

Cloud Web Security server not reachable

This counter increments when the security appliance drops HTTP or HTTPS traffic that is subject to Cloud Web Security (formerly ScanSafe) inspection because the configured cloud proxy servers are unreachable. The appliance performs periodic health checks to both the primary and backup proxy servers (if configured). When all configured servers fail their health checks, the cloud service is marked as unavailable and new connections requiring cloud inspection are dropped. Health checks verify TCP connectivity and, if application-level health checking is enabled, validate HTTP responses from the proxy service. The counter also increments if no proxy servers are configured or if the active server index is in an invalid state.

Recommendation:

Use 'show scansafe server' to verify the reachability status of your configured Cloud Web Security proxy servers. Check that both primary and backup servers (if configured) show as reachable. If servers are shown as down, verify network connectivity from the security appliance to the proxy server IP addresses and ports (typically 8080 for HTTP and 8443 for HTTPS). Confirm that any intermediate firewalls or routing devices allow traffic to the cloud proxy. Review the retry-count setting under 'scansafe general-options' to ensure sufficient retry attempts are configured. If application-level health checks are enabled with 'health-check application', verify that the proxy servers respond correctly to HTTP GET requests. Check for syslog messages 775003 (primary server down) and 775004 (all servers down) to identify when connectivity was lost. If the issue persists despite confirmed network connectivity, verify that the Cloud Web Security service itself is operational and that your license is active. This drop is expected behavior when the cloud service is unavailable and protects against sending traffic to unreachable proxies.

Syslogs:

775002, 775003, 775004, 775005, 775006

----------------------------------------------------------------

inspect-stun-invalid-pak

STUN inspection detected invalid packet

The appliance dropped a packet during STUN (Session Traversal Utilities for NAT) inspection because it failed protocol validation. STUN inspection is typically enabled to support WebRTC applications and other real-time communications that require NAT traversal. The drop occurs when the packet fails one or more validation checks: the STUN magic cookie field does not contain the expected value (0x2112A442), the packet length is negative or does not match the length declared in the STUN header, or the message type field is not recognized as a valid STUN message type (request, indication, success response, or error response). This counter may increment when non-STUN traffic is sent to UDP port 3478 (the default STUN port) or when legitimate STUN packets are malformed due to implementation bugs, corruption in transit, or deliberate manipulation.

Recommendation:

If the counter increments occasionally, no action is required—this is normal when non-STUN applications use port 3478 or when clients send malformed packets. If the counter increments frequently and affects legitimate WebRTC or STUN-based applications, verify that STUN inspection is appropriate for your environment. Use 'debug stun' to examine dropped packets and identify the specific validation failure. Check whether the traffic is actually STUN protocol or another application using the same port. If legitimate STUN traffic is being dropped, verify that clients and servers implement STUN correctly according to RFC 5389. If non-STUN traffic on port 3478 is being incorrectly inspected, consider using a service policy to exempt that traffic from STUN inspection. If the drops correlate with a specific application or client, contact TAC with packet captures and debug output for further analysis.

Syslogs:

A syslog message is generated when this drop occurs, showing the flow details (interfaces, addresses, ports) and STUN message type.

----------------------------------------------------------------

inspect-stun-out-of-memory

STUN Inspection Memory Allocation Failure

This counter increments when STUN (Session Traversal Utilities for NAT) inspection cannot allocate memory during packet processing. STUN inspection is used to support WebRTC and ICE (Interactive Connectivity Establishment) traffic through the firewall by dynamically creating pinholes for media streams. The memory allocation failure typically occurs when the inspection engine processes STUN packet attributes and the system has insufficient memory available. This can happen during periods of high connection load, memory pressure from other subsystems, or when processing a large volume of STUN traffic. The affected packets are dropped to prevent inspection from proceeding with incomplete data.

Recommendation:

Check overall system memory utilization using 'show memory' and 'show memory detail' to determine if the device is experiencing memory exhaustion. Review STUN inspection statistics with 'show service-policy inspect stun' to assess traffic volume. If memory pressure is confirmed, consider: (1) reducing the number of concurrent connections or inspection policies, (2) disabling STUN inspection if WebRTC traffic is not required in your environment, or (3) upgrading to a platform with more memory if STUN inspection is necessary and traffic volume is legitimate. If drops occur without general memory pressure, or if they persist after addressing memory issues, contact Cisco TAC for further investigation as this may indicate a memory leak or resource exhaustion condition specific to STUN inspection.

Syslogs:

None.

----------------------------------------------------------------

inspect-stun-out-of-trans-id

STUN Inspection Transaction Tracking Allocation Failure

This counter increments when STUN inspection cannot allocate memory to track a STUN transaction. STUN inspection (used for WebRTC and other NAT traversal applications) maintains a list of active transaction identifiers to correlate STUN requests with their responses before opening media pinholes. When a new STUN Binding Request or Indication arrives, the firewall attempts to allocate a small tracking structure to store the 96-bit transaction ID. If this allocation fails, the packet is dropped and this counter increments. Memory exhaustion can occur during sustained high rates of STUN traffic, memory pressure from other subsystems, or during certain attack scenarios involving rapid STUN request floods.

Recommendation:

Check overall system memory usage with 'show memory' and 'show blocks'. If memory is not critically low, this drop may indicate a STUN-specific resource exhaustion—review STUN traffic rates and consider whether the volume of concurrent STUN sessions is legitimate. If STUN inspection is enabled but WebRTC or similar applications are not in use, consider disabling STUN inspection in the default inspection policy. For legitimate high-volume WebRTC deployments, verify that STUN traffic patterns are normal (transaction IDs should be unique and responses should arrive promptly). Persistent drops with adequate system memory may indicate an attack or misconfigured client repeatedly sending STUN requests; review connection statistics and consider rate-limiting or access control adjustments. Contact Cisco TAC if drops occur with low STUN traffic volume and sufficient available memory.

Syslogs:

None.

----------------------------------------------------------------

inspect-stun-pinhole-fail

STUN inspection failed to create pinhole

The firewall dropped a packet because it could not create a dynamic pinhole (secondary connection) after successfully processing a STUN transaction. STUN inspection is used for WebRTC and other real-time communications that require dynamic pinholes through the firewall. After the firewall observes a successful STUN Binding Request and Response exchange, it attempts to create a wildcard pinhole to allow the subsequent media traffic. This counter increments when that pinhole creation fails. Common causes include system memory exhaustion, reaching the maximum connection limit (global or per-context), or internal resource allocation failures. The failure prevents the expected media traffic from traversing the firewall, breaking the real-time communication session even though the STUN signaling succeeded.

Recommendation:

Check system memory usage with 'show memory' and connection table utilization with 'show conn count'. If memory is low or connection limits are reached, investigate what is consuming resources. For multi-context deployments, verify per-context connection limits with 'show resource usage' in each context. If the system is not resource-constrained, the issue may indicate an internal allocation failure; collect 'show asp drop' output, 'show conn detail' filtered for STUN flows, and contact Cisco TAC. Review whether STUN inspection is required for your deployment—if WebRTC or similar protocols are not in use, consider disabling STUN inspection. If drops are frequent, monitor for patterns correlating with traffic spikes or specific applications.

Syslogs:

None

----------------------------------------------------------------

inspect-stun-trans-id-no-match

STUN response transaction ID does not match request

The firewall dropped a STUN (Session Traversal Utilities for NAT) response packet because its transaction identifier did not match any STUN request that previously passed through the firewall on the same connection. STUN inspection is typically enabled to support WebRTC applications (browser-based voice and video calling) and other real-time communications that require NAT traversal. When STUN inspection is active, the firewall tracks the unique transaction ID from each STUN request and validates that any success or error response carries a matching transaction ID. This validation ensures that responses correspond to legitimate requests and prevents unsolicited or spoofed STUN traffic from creating unauthorized pinholes through the firewall. This drop occurs when a STUN response arrives without a corresponding request, which can happen if the request was blocked, never sent, the transaction ID expired from the tracking table, or an attacker is attempting to inject crafted responses.

Recommendation:

If this counter increments occasionally, no action is required—it may indicate normal network behavior such as delayed responses arriving after the request tracking entry expired, or legitimate retransmissions that were already processed. If the counter increments frequently or continuously, investigate the following: verify that STUN requests from the same connection are not being blocked by access lists or other security policies; check whether the STUN client or server is misbehaving by sending unsolicited responses; review the connection for signs of attack or malicious traffic attempting to exploit STUN inspection. If the traffic is determined to be malicious, apply access control lists to block the offending source. For legitimate applications experiencing issues, ensure bidirectional traffic flow is permitted and consider adjusting timeout values if responses are delayed. Contact Cisco TAC if legitimate WebRTC or STUN-based applications are failing due to this drop.

Syslogs:

618001

----------------------------------------------------------------

intercept-unexpected

TCP intercept received unexpected packet

The device dropped a packet during TCP intercept processing because it arrived at an unexpected time in the connection establishment sequence. TCP intercept is a SYN flood protection mechanism that activates when embryonic connection limits are exceeded (configured via 'set connection embryonic-conn-max'). During intercept, the device uses SYN cookies to proxy the three-way handshake between client and server. This counter increments in several scenarios: (1) The client sent additional packets (retransmissions, data, or window probes) after its initial SYN but before the device received the server's SYN-ACK response—these are silently dropped to avoid interfering with the intercept state machine. (2) The client sent an ACK packet with payload data during the three-way handshake, which violates the intercept processing expectations. (3) A packet arrived from an unexpected direction (e.g., server-to-client) during the initial intercept state. (4) The client's ACK contained an invalid SYN cookie that could not be validated. This drop is part of normal TCP intercept operation and protects the device from malformed or attack traffic during connection establishment.

Recommendation:

Review the traffic pattern to determine if this is expected behavior or indicates an issue. If the counter increments occasionally during high connection rates or when embryonic limits are reached, this is normal TCP intercept operation protecting against SYN floods—no action is needed. If the counter increments frequently for legitimate management traffic (SSH, HTTPS to the device), verify that clients are not sending data in the third packet of the three-way handshake; some SSH/Telnet clients exhibit this non-standard behavior and may require client-side configuration changes. Check 'show conn' and 'show service-policy' to confirm embryonic connection limits and current counts. If legitimate connections are failing, consider raising the embryonic connection threshold ('set connection embryonic-conn-max') to reduce how often TCP intercept activates, or adjust the per-server limits. For troubleshooting connection failures, capture packets on both client and server sides to identify whether retransmissions, out-of-sequence packets, or data in the handshake ACK are triggering the drops. If drops persist for traffic to the device itself (management access) after software upgrades, check for known issues related to TCP intercept and management traffic.

Syslogs:

201010 (embryonic connection limit exceeded), 733104 (TCP intercept average rate threshold), 733105 (TCP intercept burst rate threshold)

----------------------------------------------------------------

interface-down

Interface is down

This counter increments when a packet is dropped because the interface it would traverse is administratively disabled (shutdown). For ingress traffic, the packet is dropped after the firewall determines which security context and interface the packet belongs to, but before any further processing. For egress traffic, the packet is dropped when the outbound interface is shut down or being removed. This also applies to VPN tunnel interfaces (VTI) and VPN access interfaces configured as unnumbered—if the numbered interface they reference is shut down, packets on the unnumbered interface will be dropped with this counter. The physical link state is not relevant; this counter tracks only the administrative (software) interface state controlled by the shutdown command.

Recommendation:

Check the administrative state of the interface shown in the drop output using 'show interface' or 'show nameif'. If the interface shows 'administratively down', it has been disabled with the 'shutdown' command. To restore traffic flow, enter interface configuration mode and issue 'no shutdown'. In multi-context deployments, verify you are in the correct context when checking interface state. For VPN tunnel interfaces, also verify that any numbered interface they reference is enabled. In high-availability configurations, confirm that interface states are synchronized between units—a known issue (CSCwt99185) can cause standby units to automatically enable interfaces that are intentionally shut down on the active unit after policy deployment; if this occurs, suspend and resume high availability on the standby unit or trigger a failover to resynchronize. If the interface should remain disabled, this counter incrementing is expected and requires no action.

Syslogs:

None.

----------------------------------------------------------------

invalid-adjacency

No valid adjacency

The device attempted to forward a packet but could not resolve the next-hop MAC address for the destination. This occurs when the device performs a routing lookup and determines the egress interface and next-hop IP address, but the ARP (for IPv4) or Neighbor Discovery (for IPv6) table does not contain a MAC address entry for that next-hop. The packet is dropped because Layer 2 forwarding requires a destination MAC address. This counter specifically tracks cases where adjacency lookup fails after routing has already determined the egress path, distinguishing it from the 'no-adjacency' counter which tracks ARP/ND resolution timeouts. Common scenarios include: traffic destined to an unreachable next-hop gateway where ARP requests receive no response; configurations with Bridge Virtual Interfaces (BVI) where the device cannot resolve the MAC address of a host on a bridge-group member interface; traffic through security zones with dynamic routing where the next-hop changes but ARP resolution has not yet completed; and transient drops during routing table updates when adjacency information becomes stale before being refreshed.

Recommendation:

Use packet capture with 'capture <name> type asp-drop invalid-adjacency' to identify which destination IP addresses are triggering the drop. Verify that the next-hop gateway or destination host is reachable and responding to ARP requests by checking 'show arp' (IPv4) or 'show ipv6 neighbors' (IPv6). If the next-hop is missing from the ARP table, investigate network connectivity to that gateway—confirm the gateway is online, that no Layer 2 issues exist (VLAN mismatches, switch port problems), and that the gateway is configured to respond to ARP. For BVI configurations, verify that the destination MAC address exists in the bridge-group MAC address table using 'show mac-address-table'. Check 'show arp statistics' to see if the control plane is dropping packets due to adjacency lookup failures, which may indicate the next-hop is persistently unreachable. If drops occur during routing changes, they may be transient and self-resolve once ARP completes; sustained drops indicate a reachability problem. For high-volume traffic to unreachable destinations, consider applying access lists to block the traffic and prevent control plane overload from repeated ARP resolution attempts. If the issue persists with confirmed reachability, contact Cisco TAC with packet captures, ARP table output, routing table output, and interface configurations.

Syslogs:

None

----------------------------------------------------------------

invalid-app-length

Invalid Application Layer Length

The device detected a malformed packet where the application layer payload is incomplete or has an invalid length field. This counter currently tracks drops from DNS inspection when a DNS packet arrives with an incomplete DNS header—for example, when the packet is truncated and does not contain the minimum required DNS header fields (transaction ID, flags, question count, answer count, authority count, and additional count). This validation occurs when DNS inspection is enabled, either through the default inspection policy or a custom DNS inspection policy map. The check protects against malformed DNS traffic that could indicate network issues, fragmentation problems, or malicious activity.

Recommendation:

This drop is typically benign and indicates the device is correctly filtering malformed DNS traffic. Common causes include: (1) Fragmented DNS packets where the first fragment does not contain the complete DNS header—DNS over UDP should normally fit within a single packet; (2) Network transmission errors causing packet truncation; (3) Malicious or crafted packets attempting to exploit DNS parsing vulnerabilities. If you see sustained increments of this counter, investigate the source of the malformed DNS traffic. Check for MTU mismatches, fragmentation issues, or misbehaving DNS clients or servers. If legitimate DNS traffic is being dropped, verify that DNS servers are not sending abnormally fragmented responses. For troubleshooting, use packet captures to examine the dropped DNS packets and confirm they are indeed malformed. No configuration change is typically required unless legitimate traffic is being affected.

Syslogs:

None

----------------------------------------------------------------

invalid-encap

Invalid Encapsulation

The firewall received a frame with an unsupported or malformed link-layer encapsulation. This occurs when the Ethernet frame type is not one of the supported formats (standard Ethernet II, IEEE 802.3 with LLC/SNAP, 802.1Q VLAN tagging, or Cisco metadata frames), or when a supported encapsulation contains invalid header fields. Common causes include: frames using unsupported protocols at the data link layer; IEEE 802.3 frames with malformed LLC headers where the DSAP and SSAP fields do not match expected values; Cisco TrustSec frames (CMD encapsulation) with invalid Security Group Tag (SGT) values—specifically SGT 65535, which is reserved and always rejected; frames with header lengths that are too short or inconsistent; and Q-in-Q (double-tagged VLAN) frames exceeding the maximum supported nesting depth. This drop typically indicates a misconfiguration on directly connected devices, non-standard frame formats from legacy equipment, or corruption during transmission.

Recommendation:

Verify that all directly connected devices are configured to use standard Ethernet II or IEEE 802.3 encapsulation. If using Cisco TrustSec inline tagging, ensure that SGT values are within the valid range of 1 to 65533; SGT 65535 is reserved and will always be dropped. Check for misconfigured VLAN tagging—particularly excessive Q-in-Q nesting—and ensure VLAN configurations match on both ends of the link. If the drops occur on a specific interface, use packet capture to examine the frame headers and identify the exact encapsulation issue. For environments with legacy equipment, confirm that all devices support the same link-layer protocol. If drops persist and the source cannot be identified, contact Cisco TAC with a packet capture showing the dropped frames.

Syslogs:

None.

----------------------------------------------------------------

invalid-encryption-packet

Packet routed to IPsec encryption without encryption flow state

This counter increments when a packet is routed to the IPsec encryption processing path, but the associated connection does not have the required encryption state marker. This indicates an internal inconsistency where the routing decision directed the packet toward IPsec encapsulation, but the connection was not properly established as an IPsec encryption flow during initial classification. This can occur during transient conditions such as IPsec tunnel reconfiguration, routing changes that redirect traffic to a VTI (Virtual Tunnel Interface) after the flow was already created, or race conditions during tunnel establishment. In rare cases, it may indicate a software defect where the encryption flow state was not correctly set during connection setup despite matching an IPsec encryption policy.

Recommendation:

Occasional increments of this counter during tunnel reconfiguration or routing changes are typically benign and represent packets caught in transition. If the counter increments rapidly and continuously, investigate the following: (1) Check for recent changes to IPsec tunnel configuration, VTI interfaces, or routing policies that might cause existing flows to be redirected to encryption paths. (2) Verify that IPsec tunnels are stable and not flapping (use 'show crypto ipsec sa' and 'show vpn-sessiondb'). (3) Review 'show conn' output for flows with mismatched interface or routing state. (4) If the issue persists without configuration changes and affects production traffic, collect 'show tech-support' and 'show asp drop' output and contact Cisco TAC, as this may indicate a flow classification defect.

Syslogs:

None

----------------------------------------------------------------

invalid-ethertype

Invalid Ethertype

The device attempted to fragment or reassemble a packet that is not IPv4 or IPv6. The fragmentation and reassembly subsystems only support IP traffic; non-IP protocols such as ARP, MPLS, or legacy protocols cannot be fragmented. This counter typically indicates a software defect where non-IP traffic incorrectly entered the fragmentation code path, or a packet with a corrupted or invalid Layer 3 protocol type. Under normal operation, non-IP protocols should bypass fragmentation processing entirely.

Recommendation:

This counter should remain at zero during normal operation. If it increments, capture the dropped packets using 'capture asp-drop invalid-ethertype' to identify the protocol type and source. Check for recent software changes, interface configuration errors, or upstream devices sending malformed frames. If the counter increments persistently, contact Cisco TAC with packet captures and the output of 'show asp drop' and 'show interface' for all affected interfaces.

Syslogs:

None.

----------------------------------------------------------------

invalid-geneve-segment-id

Invalid Geneve segment-id

The appliance attempted to encapsulate and transmit a packet through a Geneve tunnel interface but could not determine a valid Virtual Network Identifier (VNI) segment ID for the outbound packet. This occurs during egress processing when the packet lacks the necessary metadata to identify which Geneve segment should carry the traffic. Common scenarios include: packets without proper flow context (such as internally-generated TCP resets or ICMP responses), configuration mismatches where the VNI interface segment ID is not properly set, or software defects that fail to propagate segment ID information through the packet processing pipeline. In AWS Gateway Load Balancer (GWLB) deployments, this may appear when the appliance generates control packets in response to dropped traffic and those packets inherit incomplete tunnel metadata. The valid segment ID range is 1 to 16,777,215; segment ID 0 is reserved and will trigger this drop.

Recommendation:

Check the VNI interface configuration to verify that a valid segment-id is configured (use 'show interface vni' and 'show nve'). If the drops occur sporadically and correspond to internally-generated control traffic (TCP resets, ICMP unreachables), they may be benign side effects of legitimate packet drops and do not indicate a forwarding problem for user data. In AWS GWLB environments, verify that the VTEP and VNI interfaces are properly associated and that the Geneve encapsulation mode (single-arm proxy vs. standard) matches your deployment. If drops persist for user data traffic, capture packets on both the VTEP and VNI interfaces to determine whether the segment ID is missing from inbound decapsulated packets or failing to be set during flow creation. Review recent configuration changes to VNI or VTEP interfaces. If the issue appeared after an upgrade or affects production traffic, contact Cisco TAC with 'show asp drop' output, interface configurations, and packet captures.

Syslogs:

860001

----------------------------------------------------------------

invalid-geneve-segment-id-fp

Invalid Geneve segment ID

This counter increments when the security appliance receives a Geneve-encapsulated packet and cannot process it because the segment ID in the Geneve header does not match any configured VNI interface in the same security context, or because the segment ID matches the VNI interface's own originating segment ID (self-tag). The packet is decapsulated successfully but cannot be forwarded because there is no valid destination VNI interface. This occurs during fast-path processing of Geneve traffic, including AWS Gateway Load Balancer (GWLB) proxy deployments and standard Geneve overlay networks.

Recommendation:

Verify that the segment ID in the dropped Geneve packets matches a configured VNI interface segment ID on the security appliance. Use the syslog message (778003) to identify the specific segment ID value causing the drop. Check the VNI interface configuration with 'show interface vni' and 'show nve' commands to confirm segment ID assignments. Ensure that the sending VTEP or AWS GWLB is configured with the correct segment ID that corresponds to a VNI interface on this device. If the segment ID matches the VNI's own originating segment ID, this indicates a routing loop or misconfiguration where the device is receiving its own encapsulated traffic—verify VTEP peer configurations and routing to prevent traffic from being reflected back to the originating device. For AWS GWLB deployments, confirm that the GWLB target group and VNI configuration are aligned.

Syslogs:

778003

----------------------------------------------------------------

invalid-geneve-shared-ch

Invalid Geneve segment-id

The appliance dropped a Geneve packet because the segment-id (VNI) in the packet does not match any configured VNI interface. This can occur in two scenarios: (1) During decapsulation, when an incoming Geneve packet carries a segment-id that is not configured on any VNI interface in the same security context as the receiving VTEP interface. (2) During encapsulation, when the appliance attempts to send a packet through a Geneve tunnel but cannot determine a valid segment-id from the flow or interface metadata. This counter is most commonly seen in AWS Gateway Load Balancer (GWLB) deployments, particularly in cluster configurations, where internally-generated control packets (such as TCP resets) may lack the necessary encapsulation context.

Recommendation:

Check the VNI interface configuration on the appliance and verify that the segment-id values match those expected by the remote Geneve peer or AWS GWLB endpoint. Use 'show interface vni' to list configured VNI interfaces and their segment-ids (valid range: 1-16777215). If the drops occur during normal traffic flow, verify that the remote VTEP is sending packets with the correct segment-id. In AWS GWLB deployments, sporadic drops of this type at the end of TCP sessions are typically benign and result from internally-generated control packets (RST, FIN) that arrive after the flow has been torn down. If drops are frequent or affect active data flows, capture packets on both the VTEP and VNI interfaces to identify the mismatched segment-id value, then correct the configuration on either the local appliance or the remote peer. For persistent issues in cluster environments, contact Cisco TAC.

Syslogs:

860001

----------------------------------------------------------------

invalid-ip-header

Invalid IP Header Checksum

The appliance received an IPv4 packet with an incorrect header checksum. The checksum is validated either by the network interface hardware (checksum offload) or by software calculation when hardware validation is unavailable or reports an unknown status. This counter increments when the computed checksum does not match the value recorded in the packet header.

This drop typically indicates one of three conditions: (1) physical layer problems such as faulty cabling, electromagnetic interference, or failing network interface hardware causing bit corruption during transmission; (2) an upstream device or middlebox that modified the IP header without recalculating the checksum; or (3) on virtual platforms, a checksum offload configuration issue where the hypervisor or virtual NIC incorrectly reports checksum status.

Note that traffic returning from inline security modules (such as IPS, CX, or Firepower services) bypasses checksum validation because these modules prepend special headers that are not checksummed, which would otherwise trigger false positives.

Recommendation:

First, use packet capture to identify the source and characteristics of the dropped packets. If drops are sporadic and from various sources, investigate physical layer issues: check cable integrity, replace suspect cables, verify interface statistics for CRC errors or input errors, and test with known-good hardware. If drops are consistent from a specific source, verify that no middlebox between the source and the appliance is modifying IP headers without updating checksums.

On virtual platforms (FTDv, ASAv), verify that checksum offload is properly configured in the hypervisor and that the virtual NIC driver supports it. On ESXi, ensure the platform is running a version with the fix for checksum detection issues (9.16.4 or later for FTDv). Check the tech-support output for messages indicating checksum capability failures.

If drops occur only for traffic that should be inspected by inline security services, verify that the service module is functioning correctly and that traffic is being properly redirected. Persistent drops with no clear physical cause may indicate an attack or malicious traffic and should be investigated further using the captured packet data.

Syslogs:

None

----------------------------------------------------------------

invalid-ip-length

Invalid IP Length

The firewall received an IPv4 or IPv6 packet with inconsistent length information. For IPv4, this occurs when the IP header length field is less than 20 bytes, the header length exceeds the total length field, or the declared IP packet length extends beyond the received frame boundaries. For IPv6, this occurs when the payload length field plus the 40-byte base header exceeds the received frame size, or when extension header lengths cause the total header size to exceed the packet length. This counter typically indicates packet corruption in transit, truncated frames from upstream devices, or malformed packets from attackers. In rare cases, it may indicate legitimate traffic using protocols not yet recognized by the firewall's packet decoder.

Recommendation:

Investigate the source of the dropped packets using packet capture. If the counter increments steadily, check for physical layer issues (bad cables, faulty NICs, duplex mismatches) or MTU problems causing fragmentation and reassembly errors on the path to the firewall. Review the specific IP addresses and protocols being dropped—if legitimate traffic is affected, verify that the firewall software version supports the protocol in use (for example, older versions dropped IPv6 PIM packets incorrectly). If drops correlate with traffic from untrusted sources, this may indicate attack traffic and can be safely ignored. For troubleshooting, use 'capture <name> type asp-drop invalid-ip-length' without match criteria to see the full packet headers, then filter the output for specific addresses if needed.

Syslogs:

None.

----------------------------------------------------------------

invalid-ip-option

IP option validation failure

The security appliance received a packet with IP options that either violated structural requirements or was not permitted by the configured IP options inspection policy. Packets are dropped when: (1) the total IP options length exceeds 40 bytes, (2) individual option lengths are malformed or inconsistent, (3) non-zero padding appears after the end-of-options-list marker, or (4) the option type is not explicitly allowed by policy. By default, all IP options are dropped unless an IP options inspection policy is configured to permit or clear specific option types. Common legitimate uses of IP options include Router Alert for RSVP and multicast protocols (IGMP, PIM), timestamp options for network diagnostics, and record-route for path tracing.

Recommendation:

Review syslog 106012 to identify which IP options are present in the dropped packets. If the traffic is legitimate and requires IP options (such as RSVP for QoS reservations or Router Alert for multicast routing), configure an IP options inspection policy using the Modular Policy Framework to permit or clear the specific option types needed. Use 'inspect ip-options' within a policy-map and specify actions (allow or clear) for individual option types such as router-alert, timestamp, or record-route. If packets show malformed options (excessive length or invalid structure), investigate the sending device for misconfiguration or potential security issues. For VPN-encapsulated traffic with legitimate IP options, ensure the inspection policy permits the required options on the decapsulated traffic path.

Syslogs:

106012

----------------------------------------------------------------

invalid-map-address-port

Invalid MAP address/port combination

A packet from a MAP (Mapping of Address and Port) Customer Edge device has an IPv6 source address and port combination that violates the configured Basic Mapping Rule. This occurs in two scenarios: (1) The Port Set ID (PSID) encoded within the IPv6 address bits does not match the PSID derived from the source port number, indicating inconsistent address encoding per RFC 7599, or (2) The source port falls outside the port range allocated to that specific IPv6 address based on the share-ratio and start-port configuration. This counter increments when the device is operating as a MAP Border Relay and receives outbound traffic from MAP-T Customer Edge nodes. The drop protects against misconfigured or potentially malicious MAP CE devices attempting to use port numbers outside their allocated range.

Recommendation:

Verify the MAP domain configuration on both the Border Relay (this device) and the Customer Edge device generating the traffic. Check that the Basic Mapping Rule parameters (IPv4 prefix, IPv6 prefix, share-ratio, and start-port) match exactly on both sides of the MAP domain. Review syslogs 305019 (inconsistent PSID encoding in address) and 305020 (port outside allocated range) to identify the specific source addresses and ports being rejected. If the configuration is correct on both sides, the CE device may have a software defect in its MAP address/port calculation logic. Occasional drops may indicate a rogue device attempting to use unallocated ports; sustained drops from legitimate CE devices indicate a configuration mismatch that must be corrected to restore connectivity.

Syslogs:

305019, 305020

----------------------------------------------------------------

invalid-onwer-id-received

Packet dropped due to invalid cluster owner ID received

This counter increments when a cluster member receives a packet over the cluster control link with an owner ID that does not correspond to any valid member in the cluster. This occurs during flow ownership negotiation when the director or another cluster member responds with an owner assignment, but the specified owner ID is invalid, corrupted, or refers to a member that is no longer part of the cluster. The packet is dropped because the system cannot forward it to or create a flow for a non-existent cluster member. This typically happens during cluster topology changes (member join/leave events), cluster control link communication errors, or software defects that corrupt cluster metadata in transit.

Recommendation:

Check cluster health and membership status using 'show cluster info' to verify all expected members are present and active. Review 'show cluster history' for recent member join/leave events that may correlate with the drops. If drops occur continuously, examine the cluster control link for packet corruption or communication issues - check interface statistics on the cluster control link interface for errors. Verify that all cluster members are running compatible software versions. If the counter increments during normal operation without topology changes, collect a packet capture on the cluster control link and contact Cisco TAC, as this may indicate a software defect in cluster metadata handling.

Syslogs:

None.

----------------------------------------------------------------

invalid-peer-nve

Invalid Peer NVE

The device attempted to encapsulate a packet for transmission over a VXLAN or Geneve tunnel but could not retrieve valid peer tunnel endpoint information. This occurs when the Network Virtualization Edge (NVE) interface is configured to use a static peer, but either no peer IP address has been configured, or the device cannot resolve the next-hop MAC address for the configured peer. The counter increments during tunnel encapsulation when the static peer configuration is missing or incomplete, preventing the device from constructing the outer tunnel header. This typically affects deployments using static peer configuration instead of multicast-based peer discovery, particularly in environments where multicast is unavailable (such as multiple context mode) or when using point-to-point tunnel topologies.

Recommendation:

Verify that the NVE interface has a static peer IP address configured using the 'peer ip' command in NVE configuration mode. If the peer is configured, check that the device can reach the peer VTEP IP address and resolve its MAC address: use 'show route' to confirm routing to the peer, and 'show arp' (for IPv4) or 'show ipv6 neighbors' (for IPv6) to verify MAC address resolution for the next-hop toward the peer. If the peer VTEP is directly connected, ensure ARP/Neighbor Discovery is functioning on the source interface. If routing or ARP resolution is failing, address the underlying network connectivity issue. For deployments using peer groups instead of a single static peer, verify the peer-group object-group configuration. If multicast-based peer discovery is intended instead of static configuration, remove the static peer configuration and configure the appropriate multicast group on each VNI interface.

Syslogs:

778007

----------------------------------------------------------------

invalid-sctp-length

Invalid SCTP Length

The firewall received an SCTP packet that is too short to contain a valid SCTP common header. SCTP requires a minimum 12-byte header containing source port, destination port, verification tag, and checksum. This counter increments when the packet length is insufficient to accommodate this mandatory header structure. This typically indicates severely malformed or truncated packets that cannot be processed as valid SCTP traffic.

Recommendation:

This drop usually indicates one of three conditions: (1) network transmission errors or MTU issues causing packet truncation, (2) IP fragmentation problems where SCTP packets are being fragmented incorrectly, or (3) malformed packets from misconfigured or malicious sources. If you see this counter incrementing, capture traffic on the affected interface to examine the malformed packets. For legitimate SCTP traffic (commonly used in mobile/telecom signaling such as SS7 over IP), verify that intermediate network devices are not corrupting packets and that MTU settings are appropriate end-to-end. Occasional drops may indicate scanning or attack traffic and can typically be ignored. Persistent drops affecting legitimate SCTP associations require packet captures to identify the source of malformation.

Syslogs:

None.

----------------------------------------------------------------

invalid-tcp-hdr-length

Invalid TCP Header Length

The device received a TCP packet with a malformed header length field. This occurs when the header length value is less than 20 bytes (the minimum valid TCP header size) or when the declared header length extends beyond the actual packet boundaries. The packet is dropped during initial decoding or normalization processing. Legitimate causes include network transmission errors, fragmentation issues, or misbehaving network devices. Malicious causes include crafted attack packets designed to exploit protocol parsing vulnerabilities. In rare cases, hardware offload features or clustering operations may incorrectly modify headers, particularly on high-end platforms with traffic acceleration enabled.

Recommendation:

Review the syslog message to identify the source address and interface. If drops are sporadic and from diverse sources, they likely represent normal internet background noise or scanning activity and can be ignored. If drops are persistent from specific internal hosts, investigate the sending device for hardware issues, driver problems, or misconfigured TCP offload features. On Firepower 9300 platforms running FTD 6.2.3.x in transparent mode with prefilter fastpath rules, consider changing prefilter policy to Analyze or Trust to avoid hardware offload, or upgrade to a fixed software version. For clustered deployments experiencing these drops, verify all cluster members are running identical software versions. Use 'capture asp-drop invalid-tcp-hdr-length' to collect packet samples for analysis. If drops correlate with legitimate application failures, contact Cisco TAC with captures and the associated syslog messages.

Syslogs:

500003

----------------------------------------------------------------

invalid-udp-length

Invalid UDP Length

The firewall received a UDP packet where the length field in the UDP header does not match the actual size of the packet received from the network. The UDP header contains a 16-bit length field that specifies the total size of the UDP datagram (8-byte header plus payload). When this stated length is larger than the measured packet size, the packet is dropped as malformed. This validation occurs during initial packet decode before any connection processing. Common causes include: malformed or crafted packets from an attacker attempting to exploit parsing vulnerabilities; network corruption or truncation during transmission (faulty cables, switches, or NICs); intermediate devices that incorrectly modify or truncate packets; or buggy UDP stack implementations on the sending host. In cluster deployments, this check is bypassed for internal fragment flow owner messages exchanged between cluster members.

Recommendation:

Investigate the source of the malformed packets. Use packet capture on both the firewall and upstream network devices to determine where the corruption occurs. If drops are sporadic and from diverse sources, suspect network infrastructure issues such as failing switches, bad cables, or NIC driver problems. If drops are concentrated from specific hosts or subnets, investigate those endpoints for malware, buggy applications, or misconfigured UDP stack parameters. If drops occur consistently for a specific application or protocol, verify the application is generating valid UDP packets and check for any intermediate devices (load balancers, proxies, WAN optimizers) that might be corrupting packets. For persistent issues from legitimate traffic, capture the dropped packets using 'capture <name> type asp-drop invalid-udp-length' and analyze the UDP header length field versus the actual packet size. This drop is a security protection and should not be disabled; legitimate UDP traffic will not trigger it.

Syslogs:

None

----------------------------------------------------------------

invalid-vxlan-segment-id

Invalid VXLAN segment-id

The device drops a VXLAN packet because the VXLAN Network Identifier (VNI) segment ID is invalid or does not match any configured VNI interface. This occurs in two scenarios: (1) On ingress, when decapsulating a VXLAN packet whose segment ID does not match any VNI interface configured on the device, or (2) On egress, when attempting to encapsulate a packet through a VNI interface that lacks a configured segment ID or has an invalid segment ID in the flow metadata. Common triggers include VNI interfaces configured without a segment-id command, VXLAN traffic from remote peers using segment IDs not provisioned locally, tag-switching misconfigurations where segment ID translation fails, and Azure proxy-paired VNI deployments with incorrect internal or external segment ID mappings.

Recommendation:

Check the VNI interface configuration with 'show interface vni' and verify that each VNI interface has a valid segment-id configured using the 'segment-id' command. For ingress drops, compare the segment ID in syslog 778001 or 778003 against your configured VNI segment IDs to identify mismatches between the remote VTEP and local configuration. For tag-switching deployments, verify the STS (Segment Tag Switching) table mappings with 'show sts mapping' to ensure proper segment ID translation. In Azure proxy-paired configurations, confirm that internal and external segment IDs are correctly assigned and match the expected traffic direction. If drops occur after configuration changes, ensure the VNI interface has a segment-id configured before assigning a nameif or bringing the interface up. Contact Cisco TAC if drops persist with correct segment ID configuration.

Syslogs:

778001, 778003

----------------------------------------------------------------

invalid-vxlan-segment-id-fp

VXLAN packet dropped due to unrecognized segment ID

This counter increments when the device receives a VXLAN-encapsulated packet on a VTEP interface and the segment ID (VNI) in the VXLAN header does not match any configured VNI interface segment ID. During fast-path decapsulation, the device attempts to locate the destination VNI interface by looking up the 24-bit segment ID from the VXLAN header. The drop occurs when no VNI interface is configured with a matching primary segment ID, secondary segment ID, or (for Azure Gateway Load Balancer proxy-paired configurations) internal or external segment ID. This typically indicates a configuration mismatch between the sending VTEP and the receiving device, or that a VNI interface was brought up without a segment ID configured. Syslog 778003 is generated showing the invalid segment ID and the source/destination addresses.

Recommendation:

Verify VNI interface segment ID configuration using 'show interface vni' and 'show running-config interface vni'. Confirm that a VNI interface exists with a segment-id matching the value shown in syslog 778003. For standard VXLAN deployments, check the 'segment-id' command under the VNI interface. For Azure Gateway Load Balancer proxy-paired deployments, verify both 'internal-segment-id' and 'external-segment-id' are configured. Compare the configured segment IDs with the VXLAN network identifier (VNI) being sent by the remote VTEP. If the segment ID is valid but not configured locally, add the appropriate VNI interface with the matching segment ID. If the segment ID should not be received on this device, investigate the remote VTEP configuration or routing that is directing this traffic to the wrong destination.

Syslogs:

778003

----------------------------------------------------------------

invalid-vxlan-segment-id-tvi

Invalid VXLAN Segment-ID on TVI

The firewall dropped a packet because it could not find a valid VNI (VXLAN Network Identifier) interface matching the VXLAN segment-id required for forwarding. This occurs in VXLAN Source Tag Switching configurations when traffic is routed through the TVI (Tunnel Virtual Interface) but the outbound segment-id either does not match any configured VNI interface or is marked as invalid. Common scenarios include: ping commands issued from a VNI interface without a properly configured originate segment-id, packets originating from the TVI or identity interface with missing or incorrect segment-id metadata, or mismatches between the segment-id in the packet and the segment-ids configured on VNI interfaces. This drop is specific to VXLAN overlay networks using tag-switching between multiple VNI segments.

Recommendation:

Verify your VXLAN configuration: (1) Check that all VNI interfaces have valid segment-ids configured using the 'segment-id' command in interface configuration mode. (2) For VNI interfaces used with tag-switching, ensure the 'originate segment-id' is configured if you need to ping or originate traffic from that interface. (3) Use 'show vni vlan-mapping' (transparent mode) or 'show interface vni' to verify VNI interface configuration and segment-id assignments. (4) If the drops occur during SSL decryption or proxy operations, verify that VXLAN metadata is correctly preserved through the proxy path. (5) Check that the TVI interface is properly configured with an IP address if you are using tag-switching features. If drops persist after configuration verification, collect 'show asp drop' output, 'show vni detail', and packet captures to identify which segment-id is being rejected.

Syslogs:

778002, 778003

----------------------------------------------------------------

ips-fail

IPS configuration removed for connection

This counter increments when a packet belonging to an existing connection is sent to the IPS module for inspection, but the connection no longer has an associated IPS configuration. This occurs when the IPS policy applied to the connection has been removed or changed while the connection is still active. The packet is dropped because the system cannot determine how to inspect it without the configuration context. This applies only to ASA platforms with classic IPS SSM or SSP hardware modules, not to Firepower Threat Defense.

Recommendation:

This drop typically occurs during IPS policy changes or when removing IPS inspection from an interface while active connections are still being inspected. The condition is transient—new connections will use the updated configuration. If you see sustained increments, verify that IPS policy changes are being applied correctly and that the IPS module is operational (check 'show module' and 'show service-policy'). Consider timing policy changes during maintenance windows to minimize impact on active connections. If the counter increments without configuration changes, verify the IPS module health and licensing status.

Syslogs:

None

----------------------------------------------------------------

ips-fail-close

Traffic dropped when intrusion prevention module is unavailable and fail-close mode is configured

This counter increments when traffic is subject to intrusion prevention inspection but the inspection module is unavailable, and the security policy is configured to fail closed (drop traffic) rather than fail open (bypass inspection). The module may be unavailable because the hardware card is not operational, the required license is not active, or no virtual sensor has been configured to handle the traffic. Fail-close mode is a security-first policy that ensures no uninspected traffic passes through the firewall when the inspection engine cannot examine it. This behavior is by design and protects against scenarios where the intrusion prevention system is down due to hardware failure, software restart, configuration changes, or licensing issues. On ASA platforms with Advanced Inspection and Prevention Security Services Module (AIP-SSM) or SSC cards, this occurs when the physical module is not in an Up state. On Firepower Threat Defense, this occurs when the Snort inspection engine is not running or is restarting.

Recommendation:

Verify the operational status of the intrusion prevention module using the 'show module' command on ASA platforms or check Snort process health on FTD. If the module or process is down, investigate the root cause—check for hardware failures, recent configuration changes, software crashes, or license expiration using 'show activation-key'. Review syslog message 420001 for details about which traffic is being dropped. If continuous inspection is not required and traffic availability is more critical than security, consider changing the policy from fail-close to fail-open mode, which allows traffic to bypass inspection when the module is unavailable. If a virtual sensor is not configured but intrusion prevention is enabled, either configure the appropriate virtual sensor or remove the intrusion prevention policy from the affected traffic class. If the module is intentionally offline for maintenance, this drop behavior is expected and normal. Contact Cisco TAC if the module fails to come up after troubleshooting or if unexpected restarts are occurring.

Syslogs:

420001, 420008

----------------------------------------------------------------

ips-license-disabled-fail-close

IPS module license disabled with fail-close configured

This counter increments when traffic is sent to an IPS hardware module (SSP or SSM card) for inspection, but the IPS module license is not enabled and the service policy is configured with fail-close mode. In fail-close mode, the system drops all traffic destined for IPS inspection when the module cannot process it, rather than allowing the traffic to bypass inspection. This behavior ensures that no uninspected traffic passes through when IPS services are unavailable due to licensing. The counter typically appears after license expiration, license removal, or when a service policy with IPS inspection and fail-close is applied to a device without the proper IPS license entitlement.

Recommendation:

Verify the current license state with 'show activation-key' and confirm whether the IPS module license is present and valid. If the license has expired or is missing, apply a valid activation key that includes the IPS module entitlement using the 'activation-key' command. If IPS inspection is not required, either remove the IPS inspection from the service policy or change the fail-close configuration to fail-open mode to allow traffic to bypass inspection when the module is unavailable. Note that fail-open mode permits uninspected traffic and may not meet security policy requirements. If the license is correctly installed but the counter still increments, verify that the IPS module hardware is properly seated and operational.

Syslogs:

420008

----------------------------------------------------------------

ips-no-ipv6

IPv6 packet dropped due to IPS module software version

This counter increments when an IPv6 packet is configured to be inspected by an IPS SSM hardware module, but the software running on that module does not support IPv6 traffic inspection. IPS software versions prior to 6.2 lack IPv6 support. When the ASA detects an IPv6 packet destined for inspection by an older IPS module, it drops the packet rather than sending it to the module. This scenario is specific to legacy ASA 5500 series platforms with AIP SSM or IPS SSM hardware modules installed in expansion slots. The ASA determines IPv6 capability during module initialization by parsing the IPS software version string reported by the card manager.

Recommendation:

Upgrade the IPS software on the SSM module to version 6.2 or later to enable IPv6 inspection support. If upgrading is not possible, configure your service policy to exclude IPv6 traffic from IPS inspection, or configure the IPS policy in fail-open mode to allow IPv6 traffic to bypass inspection instead of being dropped. Note that this counter is only relevant for legacy ASA 5500 series platforms with physical IPS SSM modules; modern Firepower Threat Defense and ASA with FirePOWER Services do not use this architecture.

Syslogs:

None

----------------------------------------------------------------

ips-preproc

Blocked by intrusion prevention preprocessor

This counter increments when the intrusion prevention engine's preprocessor components issue a blacklist verdict that blocks traffic at the flow level. Unlike rule-based drops that evaluate individual packets, preprocessor blacklisting marks an entire connection for blocking after detecting malicious behavior, protocol violations, or reputation-based threats. Common triggers include IP reputation blacklists (when threat intelligence identifies a source or destination as malicious), protocol anomaly detection by preprocessors (such as HTTP, DNS, or SSL/TLS inspection finding policy violations), and application-layer threat detection. Once a flow is blacklisted, all subsequent packets in that connection are dropped without further inspection. This is an enforcement action, not an error condition—the intrusion prevention system is working as designed to block identified threats.

Recommendation:

Review intrusion prevention policy logs and event data to identify which preprocessor triggered the block and the specific threat or policy violation detected. Use packet tracer with capture enabled to see the detailed Snort verdict and the triggering preprocessor module. Check if the block is due to IP reputation (verify threat intelligence database is current and whitelist legitimate addresses if needed), protocol inspection (review preprocessor policies for HTTP, DNS, SSL, SIP, etc. and adjust sensitivity if false positives occur), or application detection (confirm application control policies match business requirements). If the blocked traffic is legitimate, adjust the intrusion policy to reduce false positives—either by tuning specific preprocessor rules, whitelisting trusted IP addresses or networks, or modifying the action from block to alert for specific signatures. For ongoing blocks of known-good traffic, work with your security team to update threat intelligence feeds or create policy exceptions.

Syslogs:

420002

----------------------------------------------------------------

ips-request

IPS signature matched with drop action

Traffic matched an intrusion prevention signature configured with a drop or block action. This occurs when the inline IPS inspection engine (Snort) identifies a packet or flow that matches a signature rule set to drop rather than alert. The counter increments for each packet or flow terminated by IPS policy. This is normal operation when IPS is deployed in inline mode with drop-enabled signatures. Common triggers include malware downloads, exploit attempts, policy violations, or traffic matching custom block rules. On FTD, this corresponds to intrusion events visible in the Firepower Management Center event viewer. On legacy ASA with IPS modules, this indicates the hardware or software IPS card requested the drop.

Recommendation:

Review syslog 420002 to identify the source, destination, and protocol of dropped traffic. Check the IPS event logs on Firepower Management Center (for FTD) or the IPS module (for ASA) to determine which signature triggered the drop and whether it is a true positive or false positive. If legitimate traffic is being blocked, adjust the IPS policy by changing the signature action from 'drop' to 'alert', creating an exception for the affected traffic, or tuning the signature sensitivity. If the drop is intentional and blocking malicious traffic, no action is needed. Under very high IPS processing load, legitimate traffic such as DNS replies or ICMP echo replies may occasionally be dropped; if this occurs, consider reducing the traffic sent to IPS inspection, exempting latency-sensitive protocols, or switching to promiscuous (monitor-only) mode for non-critical inspection.

Syslogs:

420002

----------------------------------------------------------------

ipsec-clearpkt-notun

IPSec clear packet with no tunnel context

The device received a packet that was decrypted by the hardware crypto engine, but the associated flow has no tunnel context attached. This indicates an internal state inconsistency where the decryption succeeded but the flow was not properly associated with the tunnel. This can occur during tunnel state transitions, such as when a tunnel is torn down or rekeyed while packets are still in flight, or in distributed architectures where the decryption and flow lookup happen on different processing nodes. Unlike the related 'ipsec-spoof' counter, this drop occurs after successful decryption when the tunnel association is missing, not when cleartext packets arrive that should have been encrypted.

Recommendation:

This counter typically indicates transient conditions during tunnel state changes and should be rare. If the counter increments steadily, investigate: (1) Check for frequent tunnel flapping or rekey events using 'show crypto ipsec sa' and 'show vpn-sessiondb detail'. (2) On platforms with hardware crypto offload (such as Firepower 4100/9300 series), verify that offload is functioning correctly with 'show crypto accelerator statistics'. (3) Review tunnel stability - frequent SA deletions and recreations can cause this condition. (4) In high-availability deployments, verify that tunnel state synchronization is working properly. If the counter increments during normal operation without tunnel state changes, contact Cisco TAC for further analysis.

Syslogs:

402117

----------------------------------------------------------------

ipsec-decrypt

Hardware-offloaded IPsec packet decryption failure

This counter increments when an inbound IPsec packet that was decrypted by hardware crypto acceleration fails validation and must be dropped. The device offloads IPsec encryption and decryption operations to dedicated hardware (FPGA-based crypto engines on Firepower 3100/4200/6100 series, or Marvell accelerators on Firepower 1200 series) to improve performance. After the hardware completes decryption, the software validates the result. Drops occur when the hardware reports a decryption error or when post-decryption validation detects problems such as: anti-replay sequence number violations (packet arrived outside the replay window or with a duplicate sequence number), authentication tag (ICV) verification failure indicating the packet was tampered with or corrupted, packet length exceeding buffer limits, Security Association (SA) lookup failures or SPI mismatches, or hardware fault conditions reported by the crypto accelerator. This counter is only relevant on platforms with IPsec hardware offload capability and when offload is enabled. It does not increment for software-decrypted IPsec traffic.

Recommendation:

Check 'show crypto ipsec sa' to identify which tunnels are experiencing decryption failures—look for incrementing 'decrypt errors' counters on specific SAs. Verify that both tunnel endpoints have matching IPsec proposals (encryption algorithm, authentication method, key lifetimes). If anti-replay drops are suspected, check 'show crypto ipsec sa detail' for replay statistics and consider whether packet reordering or high latency on the path might cause legitimate packets to arrive outside the replay window. Review 'show flow-offload-ipsec' to confirm which tunnels are hardware-offloaded and check for error counters. If drops correlate with a recent software upgrade, especially on high-availability pairs, verify that both units are running identical software versions and that failover synchronization completed successfully—known issues have caused anti-replay window desynchronization after upgrades. For persistent issues on specific platforms (particularly Firepower 1200 or 3100 series), check for known defects related to hardware offload and consider temporarily disabling offload with 'no flow-offload-ipsec' to determine if the issue is hardware-specific. Capture packets on both sides of the tunnel to identify whether corruption is occurring in transit. If authentication failures are consistent, verify pre-shared keys or certificate validity. Contact Cisco TAC if hardware fault conditions are suspected or if the issue persists after configuration validation.

Syslogs:

402119, 402121

----------------------------------------------------------------

ipsec-ipv6

IPsec packet with IPv6 outer header

The firewall received an IPsec packet (ESP, NAT-T ESP, or IPsec-over-UDP ESP) that uses IPv6 as the outer transport protocol. The device does not support IPsec tunnels where the tunnel endpoints communicate over IPv6; IPsec tunnels must use IPv4 for the outer header. This drop occurs when a remote peer attempts to establish or send traffic over an IPsec tunnel using IPv6 addresses for the tunnel endpoints themselves. Note that tunneling IPv6 traffic inside an IPv4 IPsec tunnel (IPv6 as the inner protocol) is fully supported and will not trigger this counter.

Recommendation:

Reconfigure the IPsec tunnel to use IPv4 addresses for the tunnel endpoints. If you need to carry IPv6 application traffic, configure the tunnel to encapsulate IPv6 inside the IPv4 IPsec tunnel (IPv6 as inner traffic selector). Verify that both peers are configured to use IPv4 for the IKE and IPsec outer headers. If the remote peer is outside your control and insists on IPv6 transport for IPsec, this platform cannot accommodate that configuration; consider alternative VPN technologies such as SSL VPN, which supports both IPv4 and IPv6 transport.

Syslogs:

None

----------------------------------------------------------------

ipsec-lock-error

IPsec VPN Context Lock Acquisition Failure

This counter increments when the system cannot acquire an internal lock needed to process an IPsec packet. The lock protects the IPsec tunnel state during encryption, decryption, or security association (SA) updates. Lock acquisition can fail when multiple processor cores are simultaneously processing packets or updating state for the same IPsec tunnel, creating temporary contention. This typically occurs under high traffic load when many flows are being created or torn down through a single IPsec tunnel, or during SA rekey operations when tunnel state is being updated. The condition is usually transient—packets are dropped and the counter increments, but subsequent packets succeed once the lock becomes available.

Recommendation:

Occasional increments during traffic bursts or SA rekey events are normal and do not require action. Sustained or rapidly increasing counters indicate excessive lock contention on one or more IPsec tunnels. Check for: (1) unusually high packet rates or connection rates through individual tunnels using 'show asp table vpn-context detail' to identify tunnels with high packet counts and error counters; (2) many short-lived TCP connections through IPsec, which cause frequent flow table updates; (3) multiple tunnels rekeying simultaneously. If the counter grows continuously, consider distributing traffic across multiple tunnels or reducing the connection rate. On older software versions (pre-9.20), this counter may increment more frequently due to less efficient locking; upgrading to a current release improves lock efficiency. If drops persist after load reduction, contact Cisco TAC with 'show asp drop', 'show asp table vpn-context detail', and 'show tech-support vpn' output.

Syslogs:

None.

----------------------------------------------------------------

ipsec-need-sa

IPsec tunnel SA not established

This counter increments when traffic requires IPsec encryption or decryption but no active security association (SA) exists for the tunnel. This occurs in two scenarios: outbound traffic matching a crypto policy when the tunnel is down, or inbound encrypted packets arriving for a tunnel without an established SA. During initial tunnel establishment or after a tunnel teardown, this is expected behavior—the first packet triggers IKE negotiation to establish the tunnel. The counter reflects packets dropped while waiting for the SA to be negotiated and installed.

Recommendation:

If this counter increments occasionally during tunnel startup or after idle timeouts, this is normal operation. However, if the counter increments rapidly or continuously, the tunnel negotiation is failing to complete. Verify: (1) IKE/IPsec negotiation status with 'show crypto ikev1 sa' or 'show crypto ikev2 sa' to confirm Phase 1 is completing, (2) IPsec SA status with 'show crypto ipsec sa' to verify Phase 2 establishment, (3) connectivity to the remote peer (ping, traceroute), (4) crypto configuration matches on both peers (encryption/hash algorithms, pre-shared keys, interesting traffic definitions), and (5) any firewall or routing issues preventing IKE/IPsec traffic (UDP 500, UDP 4500, ESP protocol 50). Check syslogs for IKE negotiation failures or mismatched proposals. If negotiation repeatedly fails, review the crypto configuration with 'show running-config crypto' and compare with the peer's settings.

Syslogs:

None directly associated. Check for IKE negotiation syslogs (713xxx series) and IPsec SA establishment messages (402xxx series) to diagnose why the SA is not being established.

----------------------------------------------------------------

ipsec-selector-failure

IPsec traffic selector mismatch on inbound tunnel

This counter increments when the device receives and decrypts an inbound IPsec packet, but the inner (decapsulated) packet's source address, destination address, protocol, or port numbers do not match the traffic selectors negotiated for that tunnel. Traffic selectors define which packets are permitted through an IPsec tunnel and are derived from the crypto map access list in policy-based VPN configurations or from routing in route-based VPN (VTI) configurations. When a mismatch occurs, the packet is dropped after decryption because it violates the tunnel's security policy. This typically happens when the remote peer is sending traffic through the tunnel that was not included in the original tunnel negotiation, when crypto map ACLs are mismatched between peers, or when one side has been reconfigured without renegotiating the tunnel. The counter may also increment if the remote peer is misconfigured or compromised. Syslog 402116 accompanies this drop and shows the actual packet addresses versus the expected policy selectors.

Recommendation:

Compare the crypto map access lists on both tunnel endpoints to ensure they are symmetric mirror images of each other—the local proxy on one side should match the remote proxy on the other side. Check syslog 402116 for details about which specific traffic was rejected and what the tunnel policy expected. If using policy-based VPN, verify that all legitimate traffic flows are explicitly permitted in the crypto ACL. If using route-based VPN (VTI), ensure routing is correctly configured on both sides. If the mismatch is intentional (for example, the remote peer is sending unauthorized traffic), the drops are expected and indicate the security policy is working correctly. If legitimate traffic is being dropped, either expand the crypto ACL to include the missing traffic and renegotiate the tunnel, or investigate whether the remote peer has been reconfigured without coordination. On Firepower platforms with IPsec hardware offload enabled, verify that specific port-based selectors are functioning correctly, as older software versions had issues with port number handling in offloaded tunnels.

Syslogs:

402116

----------------------------------------------------------------

ipsec-spoof

IPsec spoof detected

The device received a cleartext (unencrypted) packet that matched an inbound crypto map access list on the receiving interface. According to the local security policy, this traffic should have arrived encrypted via an established tunnel. The packet was dropped as a potential spoofing or policy violation. This typically occurs when there is a configuration mismatch between peers: the local device expects encrypted traffic for certain flows, but the remote peer is sending those flows in cleartext. Common scenarios include routing protocol packets (OSPF, BGP, EIGRP) when a crypto map is applied to the interface but the peer is not encrypting control-plane traffic, DNS queries sent to external resolvers when a site-to-site VPN policy is configured, or multicast traffic over virtual tunnel interfaces. Key management traffic (ISAKMP on UDP ports 500 and 4500) is always exempted from this check.

Recommendation:

Review the crypto map access lists on both the local device and the remote peer to ensure they match. Verify that the remote peer has an active tunnel and is configured to encrypt the traffic identified in syslog 402117. If the traffic is legitimate control-plane protocol traffic (such as OSPF hellos or BGP keepalives) that should not be encrypted, adjust the crypto map ACL to exclude it, or configure the routing protocol to use a different interface or authentication method. For site-to-site VPN scenarios, confirm that both endpoints have matching interesting traffic definitions. If the drops occur after a software upgrade, check for known issues related to routing protocol integration with IPsec policies. This counter may also increment during tunnel renegotiation or failover events; transient drops during these windows are typically benign.

Syslogs:

402117

----------------------------------------------------------------

ipsec-tun-down

IPsec tunnel is being torn down

The firewall received a packet for an IPsec tunnel that is currently being deleted. This occurs when packets arrive during the brief window between tunnel teardown initiation and flow cleanup completion. The tunnel may be torn down due to idle timeout expiration, manual clearing of the Security Association, IPsec rekey operations, crypto map configuration changes, peer-initiated deletion, or IKE negotiation failures. The associated flow is immediately freed to prevent stale tunnel state from processing traffic.

Recommendation:

This counter incrementing during normal tunnel lifecycle events (rekey, idle timeout, configuration changes, or manual 'clear crypto ipsec sa' commands) is expected and benign. Occasional increments indicate packets arrived during the teardown window and were correctly rejected. Investigate if the counter increments continuously or in large bursts, which may indicate: (1) a peer continuing to send traffic after tunnel deletion, (2) routing issues causing traffic to arrive at a firewall without an active tunnel, or (3) rapid tunnel flapping due to IKE negotiation problems. Check 'show crypto ipsec sa' to verify tunnel state, review IKE logs for negotiation failures, and confirm routing directs traffic only to devices with active tunnels. In multi-context deployments, verify contexts use distinct VPN endpoint interfaces and networks; packets looping within the same device may trigger this drop incorrectly (see CSCwk71866 for versions 9.18-9.22).

Syslogs:

None

----------------------------------------------------------------

ipsec-tun-need-swap

IPsec tunnel path switched to alternate route

This counter increments when traffic destined for an IPsec tunnel detects that the current path is no longer optimal and an alternate route is available. The device switches the connection to use the new tunnel path (typically due to Equal-Cost Multi-Path routing changes or BFD-triggered failover on Virtual Tunnel Interfaces). The specific packet that triggered the path change is dropped, but the connection flow is updated to use the new egress interface. Subsequent packets for the same connection will use the new path without being dropped. This behavior occurs when multiple IPsec tunnel paths exist to the same destination and routing conditions change—for example, when one ECMP path becomes unavailable, when BFD detects a peer failure on a VTI interface, or when routing metrics change to prefer a different equal-cost path.

Recommendation:

This is expected behavior during tunnel path failover and does not indicate a problem. A small number of drops is normal when network topology changes occur. You should see a corresponding syslog message 110004 indicating the egress interface change for affected flows. If this counter increments frequently, investigate the stability of your IPsec tunnels and routing infrastructure: check for flapping tunnel interfaces, unstable BFD sessions on VTI interfaces, or frequent ECMP path changes. Review IPsec tunnel status with 'show vpn-sessiondb' and 'show crypto ipsec sa'. For ECMP configurations, verify that all paths are stable. For BFD-enabled VTI configurations, check BFD session stability with 'show bfd neighbors'. Persistent increments may indicate underlying tunnel instability, routing oscillation, or network path issues that should be resolved.

Syslogs:

110004

----------------------------------------------------------------

ipsecudp-keepalive

IPsec over UDP keepalive received

The device received and silently dropped an IPsec-over-UDP keepalive packet. These keepalives are sent by remote VPN peers to maintain NAT or PAT session state on intermediate network devices between the peer and the appliance. This counter increments only when IPsec-over-UDP is configured with a custom UDP port (via the ipsec-udp-port command in a group policy). These keepalives are distinct from standard NAT-T keepalives, which use UDP port 4500 and are tracked separately. The keepalive packets contain a single-byte 0xFF marker or 0xFF followed by the SPI, and are intentionally dropped after being identified—they serve only to refresh NAT bindings and require no further processing.

Recommendation:

This counter incrementing is normal and expected behavior when IPsec-over-UDP is configured. The keepalives are working as designed to prevent NAT timeout issues. No action is required. If this counter increments but IPsec-over-UDP is not configured on your device, verify your network configuration—another device may be sending IPsec-over-UDP traffic to your appliance. Check for misconfigured VPN peers or group policies that reference your device's IP address. If IPsec-over-UDP tunnels are experiencing connectivity problems despite keepalives being received, verify that the custom UDP port configured in the group policy matches the peer configuration and that intermediate firewalls permit bidirectional UDP traffic on that port.

Syslogs:

None

----------------------------------------------------------------

ipv6-ah-denied

IPv6 packet dropped by extension header inspection policy

This counter increments when the appliance receives an IPv6 packet containing an Authentication Header (AH) extension header and an active inspection policy is configured to drop such packets. AH is an IPsec protocol that provides connectionless integrity and data origin authentication for IPv6 packets. The drop occurs because of an explicit administrator configuration in an IPv6 inspection policy, not due to a protocol violation or malformed packet. This is expected behavior when the policy is designed to block IPsec AH traffic or restrict certain IPv6 extension header types for security reasons.

Recommendation:

Review the IPv6 inspection policy configuration to determine if dropping AH headers is intentional. Use 'show service-policy inspect ipv6' to view the active policy and 'show running-config policy-map type inspect ipv6' to examine the configuration. If legitimate IPsec traffic using AH is being blocked, modify the policy map to remove the 'drop' action under 'match header ah', or apply a different inspection policy to interfaces where AH traffic should be permitted. If the drops are intentional (for example, to enforce a security policy that prohibits IPsec AH), no action is required. Syslog 325004 will identify the specific flows being dropped.

Syslogs:

325004

----------------------------------------------------------------

ipv6-bad-eh

IPv6 packet dropped due to invalid extension header

The device received an IPv6 packet with an extension header that violates RFC 2460 compliance rules. This counter increments when IPv6 inspection is configured with extension header type validation (via 'policy-map type inspect ipv6' with 'parameters verify-header type'). Three conditions trigger this drop: (1) the packet contains an unrecognized extension header type not in the standard set (Hop-by-Hop Options, Destination Options, Routing, Fragment, Authentication Header, Encapsulating Security Payload, or Mobility), (2) the packet contains duplicate extension headers (except Destination Options, which may legally appear twice), or (3) extension headers appear in the wrong order according to RFC 2460. This is a security feature that prevents potentially malicious or malformed IPv6 packets from being forwarded. Syslog 325005 accompanies the drop and identifies which specific violation occurred (unrecognized header, duplicate header, or wrong order).

Recommendation:

Review syslog 325005 to determine the specific violation. If the traffic is legitimate and uses non-standard or experimental IPv6 extension headers, you can disable extension header type checking by removing 'verify-header type' from the 'parameters' section of your 'policy-map type inspect ipv6'. Note that disabling this check reduces security posture by allowing unrecognized extension headers to pass. If the violation is 'duplicate extension header' or 'wrong extension header order', the source is likely sending malformed packets; investigate the sending device or application. For production traffic that must comply with RFC 2460, work with the application owner to correct the IPv6 packet structure. If drops persist with legitimate traffic and you cannot modify the source, contact Cisco TAC to evaluate whether the inspection policy is too strict for your environment.

Syslogs:

325005

----------------------------------------------------------------

ipv6-bad-eh-order

IPv6 extension headers not in RFC 2460 order

This counter increments when the appliance receives an IPv6 packet whose extension headers violate the ordering requirements defined in RFC 2460. Extension headers must appear in a specific sequence: Hop-by-Hop Options, Destination Options (first occurrence), Routing, Fragment, Authentication Header (AH), Encapsulating Security Payload (ESP), Destination Options (second occurrence), and finally the upper-layer protocol header. This validation occurs only when 'verify-header order' is configured under 'parameters' in a 'policy-map type inspect ipv6' applied to the traffic. Common violations include routing headers appearing after destination options when they should precede them, or any header appearing after the second destination options header (which must be immediately followed by the upper-layer protocol). The appliance drops the packet and generates syslog 325005 or 325006 identifying the specific ordering violation.

Recommendation:

First, verify whether strict RFC 2460 ordering enforcement is required for your environment. Many legitimate IPv6 implementations may send extension headers in non-standard orders that are functionally valid but technically non-compliant. If the traffic is from trusted sources and the ordering violation is benign, disable the check by configuring 'no verify-header order' under 'parameters' in the relevant 'policy-map type inspect ipv6'. If strict compliance is required, use packet captures to identify the source of the non-compliant traffic and work with the sending device vendor or administrator to correct the header ordering. Review syslog messages 325005 and 325006 to identify which specific header types are out of order. If drops persist from legitimate traffic sources after vendor consultation, consider disabling order verification for that traffic class.

Syslogs:

325005, 325006

----------------------------------------------------------------

ipv6-dest-option-denied

IPv6 packet dropped due to Destination Options extension header policy

This counter increments when the device receives an IPv6 packet containing a Destination Options extension header and a configured inspection policy explicitly denies this header type. The Destination Options header (IPv6 next header type 60) carries optional information examined by destination nodes and can appear up to twice in an IPv6 packet—once before a Routing header and once before the upper-layer protocol. By default, the device permits Destination Options headers; this drop occurs only when you have applied a custom IPv6 inspection policy that matches and drops this header type. The policy is enforced during fast-path processing before the packet reaches connection setup or forwarding logic.

Recommendation:

Review your IPv6 inspection policy configuration using 'show run policy-map type inspect ipv6'. Look for 'match header destination-option' with action 'drop' or 'drop log'. If legitimate traffic requires Destination Options headers (common in mobile IPv6, segment routing, or certain tunneling scenarios), either remove the drop action for this header type or apply a more permissive inspection policy to the affected traffic class. If the drops are intentional for security hardening, no action is needed. Syslog 325004 identifies the specific flows being dropped. Note that Destination Options headers are legitimate per RFC 8200 and dropping them may break standards-compliant IPv6 applications.

Syslogs:

325004

----------------------------------------------------------------

ipv6-eh-count-denied

IPv6 packet exceeds configured extension header count limit

This counter increments when an IPv6 packet contains more extension headers than the maximum allowed by the configured inspection policy. The limit is enforced through an IPv6 inspection policy-map that specifies the maximum number of extension headers permitted in a single packet. When a packet exceeds this threshold, it is dropped as a security measure to prevent extension header-based attacks or resource exhaustion. The counter applies to the total count of all extension header types (Hop-by-Hop Options, Destination Options, Routing, Fragment, Authentication Header, ESP, etc.) present in the packet, not to any single header type. This is a policy-driven drop that occurs only when IPv6 inspection with header count limits is explicitly configured and enforced on the traffic.

Recommendation:

Review the IPv6 inspection policy applied to the affected traffic. Check the 'policy-map type inspect ipv6' configuration for 'match header count gt' statements with 'drop' actions. If legitimate traffic requires more extension headers than currently allowed, increase the configured limit to accommodate the expected header count. If the drops are intentional (blocking packets with excessive extension headers for security), no action is needed. To troubleshoot: use packet captures to verify the actual number of extension headers in dropped packets, review syslog message 325004 for details about the dropped traffic, and confirm that the inspection policy is applied to the correct traffic class. If legitimate application traffic is being dropped unexpectedly, adjust the count threshold or modify the class-map to exclude that traffic from the restrictive policy.

Syslogs:

325004

----------------------------------------------------------------

ipv6-eh-inspect-failed

IPv6 extension header inspection failed due to memory allocation failure

This counter increments when the device cannot allocate memory needed to inspect IPv6 extension headers. When IPv6 packets arrive and IPv6 inspection is enabled (either through default inspection or an explicit policy-map), the device must allocate a small temporary structure to analyze the extension header chain. If this allocation fails due to memory pressure, the packet is dropped and this counter increments. This is a symptom of system-wide memory exhaustion affecting the data path, not a configuration issue or a problem with the IPv6 packet itself. The drop protects the device from attempting inspection without sufficient resources.

Recommendation:

Check overall system memory health with 'show memory' and 'show memory detail'. Look for memory pools with low free percentages or high allocation failures. If memory exhaustion is occurring, identify the root cause—common sources include connection table exhaustion, memory leaks in specific features, or insufficient memory for the traffic load. Review 'show conn count' and compare against platform limits. If drops are frequent and memory appears healthy, contact Cisco TAC with the output of 'show tech-support' and 'show asp drop' to investigate potential memory allocation issues in the data path. This counter should normally be zero; any increments indicate the device is under memory stress.

Syslogs:

None

----------------------------------------------------------------

ipv6-esp-denied

IPv6 packet with ESP dropped by extension header inspection policy

This counter increments when the firewall receives an IPv6 packet containing an Encapsulating Security Payload (ESP) header and an active inspection policy explicitly denies ESP headers. ESP is commonly used for IPsec encryption and appears as an IPv6 extension header (protocol 50) or as the upper-layer protocol in IPv6 packets. The drop occurs during extension header inspection when a configured policy map contains a rule that matches ESP headers with a drop action. This is an intentional, policy-driven drop—not a malfunction. The counter typically increments in environments where administrators have configured granular IPv6 extension header filtering to block specific header types for security or compliance reasons, but legitimate IPsec traffic is traversing the firewall.

Recommendation:

Review your IPv6 inspection policy configuration to determine if ESP should be permitted. Use 'show run policy-map type inspect ipv6' to view active policies, and look for 'match header esp' rules with a 'drop' or 'drop log' action. If you need to allow IPsec traffic, either remove the ESP drop rule from the policy map or modify the class-map to exclude legitimate IPsec flows. If ESP traffic should be blocked for security reasons, this counter indicates the policy is working as intended. When troubleshooting unexpected IPsec connectivity issues over IPv6, check whether an inspection policy is inadvertently blocking ESP headers. The accompanying syslog 325004 will identify the specific policy map and flow details.

Syslogs:

325004

----------------------------------------------------------------

ipv6-fragment-denied

IPv6 packet dropped due to fragmentation extension header policy

The appliance received an IPv6 packet containing a fragmentation extension header and dropped it because an administrator-configured inspection policy explicitly denies fragmentation headers. This occurs when a service policy applies an IPv6 inspection policy-map that includes 'match header fragmentation' with a 'drop' action. The counter increments for every IPv6 packet carrying a fragment header (protocol 44) that matches the deny rule, regardless of whether the packet is actually fragmented (first fragment, subsequent fragment, or atomic fragment with offset zero). This is an intentional security control, not a malfunction—administrators configure this policy to block IPv6 fragmentation for security hardening, as fragmentation headers can be exploited to evade inspection or facilitate reassembly-based attacks.

Recommendation:

If fragmentation should be blocked: This is expected behavior. The policy is working as designed. Review the traffic source to determine why fragmented IPv6 packets are arriving—legitimate applications should avoid fragmentation when possible by respecting path MTU discovery. If fragmentation must be allowed: Modify the IPv6 inspection policy-map applied to the affected interface. Either remove the 'match header fragmentation' clause entirely, or change its action from 'drop' to 'log' (to monitor without blocking). Use 'show service-policy' to identify which policy-map is active, then edit it under 'policy-map type inspect ipv6'. If you are unsure whether fragmentation is required for your traffic, enable logging first ('log' action) to observe fragmentation patterns before deciding whether to permit or continue blocking.

Syslogs:

325004

----------------------------------------------------------------

ipv6-hop-by-hop-denied

IPv6 hop-by-hop extension header denied by inspection policy

This counter increments when the appliance receives an IPv6 packet containing a hop-by-hop extension header and an active IPv6 inspection policy explicitly denies this header type. Hop-by-hop headers carry optional information examined by every router along the packet's path. The drop occurs only when you have configured a policy-map of type 'inspect ipv6' with a 'match header hop-by-hop' clause and a 'drop' action, and applied it via a service policy. This is intentional policy enforcement based on your security requirements, not an error condition. Syslog 325004 is generated for each dropped packet if logging is enabled in the policy.

Recommendation:

Review your IPv6 inspection policy configuration to determine if blocking hop-by-hop headers is appropriate for your environment. To view the active policy, use 'show service-policy inspect ipv6'. If legitimate traffic is being dropped, modify the policy-map to either remove the 'match header hop-by-hop' clause entirely or change the action from 'drop' to 'log' (monitoring only). If the drops are intentional and align with your security posture, no action is required. Note that some legitimate IPv6 applications and network management protocols may use hop-by-hop headers; blocking them may impact functionality such as router alerts or jumbo payload notifications.

Syslogs:

325004

----------------------------------------------------------------

ipv6-mobility-denied

IPv6 mobility extension header dropped by inspection policy

This counter increments when the appliance receives an IPv6 packet containing a Mobility extension header (used by Mobile IPv6 for handoff and location management) and an IPv6 inspection policy has been configured to drop packets with this header type. The Mobility header (protocol 135) is used in Mobile IPv6 deployments to support binding updates, care-of address registration, and mobile node handoffs. By default, if no IPv6 inspection policy is applied, mobility headers are permitted. The drop occurs only when an administrator has explicitly configured a policy-map of type 'inspect ipv6' with a 'match header mobility' clause set to drop, and that policy is applied to an interface via a service policy.

Recommendation:

Review your IPv6 inspection policy configuration using 'show run policy-map type inspect ipv6' to identify which policy is dropping mobility headers. If Mobile IPv6 (MIPv6) is required in your environment—for example, to support mobile devices maintaining connectivity during network handoffs—modify the policy-map to either remove the 'match header mobility' clause or change its action from 'drop' to 'log' or allow. If Mobile IPv6 is not used in your network, this drop is expected security behavior and no action is needed. The accompanying syslog 325004 identifies the specific source and destination of dropped packets, which can help determine whether legitimate Mobile IPv6 traffic is being blocked or if this is filtering unwanted traffic as intended.

Syslogs:

325004

----------------------------------------------------------------

ipv6-mobility-type-denied

IPv6 Mobility extension header dropped by inspection policy

This counter increments when the appliance receives an IPv6 packet containing a Mobility extension header (used by Mobile IPv6 / RFC 6275) and your configured IPv6 inspection policy explicitly drops this header type. Mobility headers enable mobile devices to maintain connectivity while roaming between networks by updating their location with home agents and correspondent nodes. By default, all mobility header types (binding updates, binding acknowledgments, home test messages, etc.) are configured to drop and log. This drop occurs during IPv6 extension header inspection in the data path when traffic matches a class with an applied IPv6 inspection policy that includes a drop action for mobility headers.

Recommendation:

Review your IPv6 inspection policy configuration under 'policy-map type inspect ipv6' to verify whether mobility header filtering is intentional. If your network does not use Mobile IPv6 (most enterprise networks do not), this drop is expected security hardening and no action is needed. If you need to permit Mobile IPv6 traffic, modify the inspection policy to remove the drop action for 'match header mobility type' or adjust the specific mobility type range being blocked. Check the accompanying syslog message 325004 to identify the source and destination of dropped packets. If drops occur unexpectedly, verify that legitimate Mobile IPv6 traffic is not being blocked, or confirm that the traffic is unwanted and the policy is working as designed.

Syslogs:

325004

----------------------------------------------------------------

ipv6-routing-type-denied

IPv6 routing extension header denied by inspection policy

The appliance dropped an IPv6 packet because it contained a routing extension header whose routing type value is denied by the configured inspection policy. IPv6 routing headers (extension header type 43) include a routing type field that specifies the routing algorithm; different type values enable different routing behaviors. You can configure the appliance to permit or deny specific routing type values using an inspection policy. Note that Routing Header Type 0 (RH0) is always dropped regardless of policy configuration, as this routing type was deprecated by RFC 5095 due to security vulnerabilities that enable amplification attacks. This counter increments for both user-configured denials and the automatic RH0 blocking. The drop occurs during stateful IPv6 inspection when the appliance examines extension headers in transit packets.

Recommendation:

Review your IPv6 inspection policy configuration to determine whether the drop is intentional. Use 'show run policy-map type inspect ipv6' to view configured policies and look for 'match header routing-type' statements with 'drop' actions. If the traffic is legitimate and should be permitted, modify the policy to allow the specific routing type value. If you are seeing drops of Routing Header Type 0 traffic, this is expected security behavior and the traffic should remain blocked. To identify which routing type values are being dropped, enable syslog 325004 and examine the logged packets. If you need to permit IPv6 routing headers but want to maintain security, consider allowing only specific routing type values that your network requires rather than permitting all types. Contact Cisco TAC if you observe unexpected drops of legitimate IPv6 traffic or need assistance designing an appropriate IPv6 inspection policy for your environment.

Syslogs:

325004

----------------------------------------------------------------

ipv6-sp-security-failed

IPv6 through-the-box security check failed

The firewall dropped an IPv6 packet attempting to transit the device because it failed one of three security checks: (1) the source and destination addresses are identical, indicating a potential spoofing or looping attack; (2) either the source or destination address is a link-local address (fe80::/10 range), which is not routable beyond the local network segment; or (3) the destination address is a multicast address (ff00::/8 range). These checks apply only to through-the-box traffic—packets destined to or originating from the firewall itself are not subject to these restrictions. Link-local addresses are used for neighbor discovery and on-link communication and should never appear in routed traffic. Multicast routing through the firewall requires explicit multicast routing configuration and uses different forwarding paths.

Recommendation:

Examine the dropped traffic using packet capture to identify the source. If you see identical source and destination addresses, investigate the sending host for misconfiguration or compromise—this pattern often indicates malicious activity or a serious stack error. If you see link-local addresses (fe80::) in through-the-box traffic, the sending device is misconfigured; link-local addresses must not be used as source or destination addresses for routed packets. Verify that hosts have properly configured global unicast addresses and default gateways. If you see multicast destinations being dropped and multicast routing is required, ensure IPv6 multicast routing is enabled and properly configured on the relevant interfaces. If the traffic is legitimate local-segment communication (such as neighbor discovery or router advertisements), it should not be transiting the firewall at all—check your network topology and routing configuration.

Syslogs:

106016 (identical source and destination only)

----------------------------------------------------------------

l2_acl

Layer 2 ACL Deny

The firewall denied a packet based on a configured or implicit layer 2 access control list. The device maintains default layer 2 filtering rules that vary by firewall mode. In routed mode, the device permits IPv4, IPv6, and ARP traffic by default, along with specific multicast destination MAC addresses for IPv4 (01:00:5E:00:00:00 through 01:00:5E:FE:FF:FF) and IPv6 (33:33:00:00:00:00 through 33:33:FF:FF:FF:FF), plus broadcast traffic (FF:FF:FF:FF:FF:FF). In transparent mode, the device additionally permits BPDU traffic (01:80:C2:00:00:00 and 01:00:0C:CC:CC:CD) and AppleTalk multicast (09:00:07:00:00:00 through 09:00:07:FF:FF:FF). All other layer 2 traffic is implicitly denied unless explicitly permitted by a user-configured ethertype access list. This counter increments when a packet matches a deny rule in either the implicit default ruleset or an explicitly configured ethertype ACL applied to an interface.

Recommendation:

Review the traffic being dropped to determine if it is expected. If the device is in transparent mode and legitimate non-IP traffic (such as specific protocol ethertypes or non-standard multicast addresses) is being blocked, configure an ethertype access list to permit the required traffic and apply it to the appropriate interface using the access-group command. Note that ethertype ACLs match on protocol type and destination MAC address patterns, not individual MAC addresses. If you see this counter incrementing for BPDU traffic on versions 9.6(2) or later, be aware that BPDU matching changed—use 'dsap 0x42' instead of the 'bpdu' keyword in your ethertype ACL. Remember that packets permitted by layer 2 ACLs may still be subject to layer 3 and layer 4 access control lists. If the drops are for unwanted traffic, no action is required.

Syslogs:

106027

----------------------------------------------------------------

l2_acl_vxlan

Layer-2 ACL drop for VXLAN tag-switching traffic

This counter increments when the firewall drops a VXLAN packet during Layer-2 ACL processing because it cannot determine the egress VXLAN segment identifier. This occurs specifically in VXLAN Service Tag Switching (STS) deployments when the firewall receives non-IP traffic (such as ARP) on a VNI interface and attempts to forward it to another segment. The firewall looks up the ingress VXLAN segment-id in the tag-switching table to find the corresponding egress segment-id, but the lookup fails because no mapping exists. This typically happens when the tag-switching table is incomplete, misconfigured, or has not been properly synchronized from the fabric controller. The drop protects against forwarding traffic to an unknown or invalid destination segment.

Recommendation:

Verify that the VXLAN tag-switching table is correctly configured and populated. Use 'show vxlan tag-switching' to display the current tag-switching mappings and confirm that entries exist for the ingress segment-id shown in the associated syslog 779001. If using a fabric controller (such as Cisco ACI APIC), verify connectivity and ensure the controller has successfully pushed the tag-switching table to the firewall. Check 'show vxlan interface' to confirm all VNI interfaces have the correct segment-id assignments. If the table appears empty or incomplete, check for syslog 779003 which indicates failures reading the tag-switching table from the controller. In environments where tag-switching is not required, ensure VNI interfaces are not inadvertently configured for tag-switching mode. Contact Cisco TAC if the tag-switching table appears correct but lookups continue to fail.

Syslogs:

779001

----------------------------------------------------------------

l2_same-lan-port

Same Interface for Source and Destination

The device dropped a frame because the Layer 2 destination lookup determined that the egress interface would be the same as the ingress interface. This occurs in two scenarios: (1) In transparent firewall mode, where interfaces operate in promiscuous mode and receive all frames on the local network segment, including traffic between other devices that does not need to transit the firewall. (2) In routed mode with Bridge Virtual Interfaces (BVI), when intra-BVI traffic is processed using Layer 2 forwarding and the MAC lookup resolves to the same physical interface. The device correctly identifies that forwarding a frame back out the interface it arrived on would create a loop, and drops it instead.

Recommendation:

This counter incrementing is normal and expected behavior, not an error condition. In transparent mode, it indicates the firewall is correctly filtering out local-segment traffic that should not be bridged. The counter will increment whenever devices on the same physical network segment communicate directly with each other, which is the intended behavior. No action is required unless the counter is incrementing for traffic you expect to transit the firewall—in that case, verify your bridge group configuration and check the MAC address table (using 'show mac-address-table') to ensure MAC addresses are learned on the correct interfaces. For BVI configurations in routed mode, verify that member interfaces are correctly assigned to their respective bridge groups.

Syslogs:

None

----------------------------------------------------------------

loopback-buffer-full

Loopback buffer full

Packets are dropped when the internal queue used to forward traffic between security contexts through shared interfaces becomes full. In multi-context mode, when a packet must traverse from one context to another context via a shared interface, the system uses an internal loopback mechanism to reinject the packet. This counter increments when the loopback queue has no available buffer space to accept additional packets. The queue fills when the system cannot process inter-context traffic fast enough, typically due to high CPU utilization, sustained high traffic rates between contexts, or resource contention on the shared interface. This drop is specific to multi-context deployments with shared interfaces and does not occur in single-context mode or when contexts use dedicated (non-shared) interfaces.

Recommendation:

Check CPU utilization with 'show cpu usage' to identify if the system is overloaded. If CPU is consistently above 80%, investigate the processes consuming CPU and consider rate-limiting or redistributing traffic. Review 'show context' to identify which contexts share interfaces and examine traffic patterns between them. If specific contexts generate excessive inter-context traffic, consider redesigning the network topology to reduce cross-context forwarding or allocating dedicated interfaces instead of shared ones. Monitor 'show interface' statistics on shared interfaces for errors, overruns, or saturation. If drops persist under normal CPU load, contact Cisco TAC with output from 'show asp drop', 'show context detail', 'show interface', and 'show cpu usage' for further analysis.

Syslogs:

None

----------------------------------------------------------------

loopback-count-exceeded

Loopback Count Exceeded

The packet was dropped because it exceeded the maximum number of times it can be reinjected into the forwarding path. Packet reinjection occurs when traffic must be processed through multiple stages, such as IPsec decryption followed by routing, NAT with policy-based routing, or when packets traverse between security contexts through shared interfaces. The system enforces a maximum iteration limit to prevent infinite routing loops. When a packet is reinjected more times than this limit allows, it is dropped and this counter increments. Common scenarios include: packets bouncing between multiple security contexts due to misconfigured routing or interface assignments; IPsec traffic in clustered deployments during topology changes; ECMP configurations where a loopback interface is used as the traffic source; and policy-based routing combined with NAT that creates circular forwarding paths.

Recommendation:

Examine your configuration for routing loops or circular forwarding paths. In multiple context mode, verify that routing tables and interface assignments do not cause packets to bounce between contexts—check that each context has a valid exit path and that shared interface configurations are correct. For VPN deployments, especially in clustered environments, verify that routing is stable after any cluster membership changes or failover events. If using ECMP with loopback interfaces as traffic originators, ensure the routing configuration does not create reinjection loops. Review policy-based routing rules combined with NAT to confirm they do not redirect traffic in circles. Enable packet capture or debug logging to identify which traffic is being dropped and trace the forwarding path. If drops occur during normal operation without obvious misconfigurations, contact Cisco TAC with the output of 'show asp drop', 'show route', 'show interface', and relevant configuration sections.

Syslogs:

None

----------------------------------------------------------------

loopback-ifc-not-found

Loopback output interface not found

The packet was queued for internal loopback processing but the required egress interface information was missing from the packet metadata. Loopback processing is used when packets must be re-injected into the data path for additional processing, such as when traffic crosses between security contexts through a shared interface, after IPsec tunnel decryption, or during policy-based routing. This drop indicates the packet reached the loopback queue without the necessary egress interface reference, preventing the system from determining where to reinject the packet.

Recommendation:

This condition typically indicates an internal software inconsistency rather than a configuration issue. It may occur during interface state transitions in multi-context deployments with shared interfaces, or during rapid configuration changes affecting interface assignments. If this counter increments during normal operation, collect the output of 'show asp drop', 'show interface', 'show context' (in multi-context mode), and 'show tech-support' and contact Cisco TAC for analysis. Transient increments during interface or context configuration changes may be expected, but sustained or frequent drops warrant investigation.

Syslogs:

None

----------------------------------------------------------------

loopback-lock-failed

Loopback lock failed

The device drops packets when forwarding traffic between security contexts that share a physical interface. In multi-context deployments, when a packet must be sent from one context to another through a shared interface, the device uses an internal loopback mechanism to reinject the packet into the correct context. This reinjection process requires acquiring an asynchronous lock to prevent race conditions. This counter increments when the lock cannot be acquired, typically due to resource contention or queue exhaustion in the packet processing subsystem. The drop protects system stability by preventing packets from being processed without proper serialization.

Recommendation:

This counter should remain at zero during normal operation. Non-zero values indicate the device is experiencing resource pressure in the packet forwarding path, specifically in the asynchronous lock subsystem used for inter-context traffic on shared interfaces. Check for high CPU utilization, memory pressure, or excessive traffic rates between contexts sharing interfaces. Review the configuration to ensure contexts are not oversubscribed. If the counter increments persistently under normal load conditions, contact Cisco TAC as this may indicate a software defect or platform resource limitation.

Syslogs:

None

----------------------------------------------------------------

lu-invalid-pkt

Invalid Logical Update Packet

The standby unit received a malformed or corrupted packet on the stateful failover link. This counter increments when the standby unit detects packets with invalid IP version fields or non-IP frames (excluding ARP) on the stateful link interface. This drop is specific to platforms using UDP-based high availability transport, which includes ASAv unlimited and certain hardware platforms. The counter typically indicates physical layer issues affecting the stateful failover link, such as cable problems, interface errors, or electromagnetic interference. Low, intermittent increments may be benign and caused by transient network conditions. Sustained or rapidly increasing drops suggest a persistent problem that can degrade stateful failover synchronization and potentially cause failover events.

Recommendation:

Check the physical health of the stateful failover link: verify cable integrity, check for interface errors with 'show interface' on the stateful link interface, and look for CRC errors or input errors. Review 'show failover' output to confirm the stateful link status is 'up' and that logical update statistics show successful message exchange. If drops are low and intermittent (a few per hour), monitor but no immediate action is required. If drops are sustained or increasing rapidly, investigate physical connectivity issues including cable replacement, checking for duplex mismatches, and verifying that no intermediate devices are corrupting frames. For virtual platforms (ASAv), check the hypervisor network configuration and virtual switch health. If physical connectivity appears healthy but drops persist, contact Cisco TAC with the output of 'show failover', 'show interface' for the stateful link, and 'show asp drop' history.

Syslogs:

None

----------------------------------------------------------------

mcast-in-nonactive-device

Multicast packet received on standby unit in HA pair

The device is configured for High Availability (failover) and is currently in standby state. A multicast packet was received and dropped because only the active unit in an HA pair processes multicast traffic. The standby unit drops all multicast packets to prevent duplicate forwarding and maintain consistent multicast routing state. This behavior applies to both IPv4 and IPv6 multicast traffic and is enforced early in the packet processing path before flow lookup.

Recommendation:

This drop is expected and by design when operating in an HA configuration. The standby unit should not forward multicast traffic. If you see this counter incrementing:

1. Verify the device is correctly in standby state using 'show failover state'.

2. Check your network topology - multicast traffic should be directed to the active unit's interfaces, not the standby unit. Review upstream switch configurations and routing to ensure multicast flows reach the active unit.

3. If multicast traffic is being flooded to both units due to Layer 2 topology (e.g., shared broadcast domain), this is normal and the drops are benign. The active unit will process the traffic correctly.

4. After a failover event, verify multicast routing state has transitioned properly on the new active unit using 'show pim topology' and 'show mroute'.

No action is required unless multicast forwarding is not working on the active unit, in which case troubleshoot multicast routing configuration and PIM neighbor relationships on the active device.

Syslogs:

None.

----------------------------------------------------------------

memif-non-ip-pkt

MEMIF Non-IP Packet

This counter increments when a non-IP packet (such as ARP, DHCP, or other Layer 2 protocol) is received on a memory interface used for inter-process communication between the firewall engine and the routing dataplane. This architecture is specific to virtual FTD platforms where the Vector Packet Processing (VPP) dataplane handles routing and forwards packets to the firewall engine for security policy evaluation. The memory interface path only supports IPv4 and IPv6 packets for policy lookup; non-IP protocols cannot be processed through this channel and are dropped. This typically occurs when Layer 2 protocols are inadvertently sent to the policy lookup path instead of being handled directly by the routing dataplane.

Recommendation:

This drop is expected behavior on virtual FTD platforms when non-IP traffic reaches the inter-process policy lookup path. If you see this counter incrementing, verify that your network configuration is not generating unexpected Layer 2 protocol traffic (such as ARP or DHCP) that should be handled locally by the routing dataplane. Check for misconfigurations in virtual network settings, VLAN tagging, or bridging that might be forwarding non-IP frames to the firewall engine. If the counter is incrementing rapidly or causing connectivity issues, collect a packet capture to identify the source and type of non-IP traffic, and review your virtual platform network configuration. This counter is not relevant on hardware FTD platforms.

Syslogs:

None.

----------------------------------------------------------------

memif-non-policy-pkt

Memory Interface Packet Missing Policy Lookup Flag

This counter increments when a packet arrives on a memory interface without the required policy lookup flag. Memory interfaces are internal communication channels used on Firepower 4100, 4200, and 9300 platforms to pass packets between the VPP data plane and the security engine for policy evaluation. These interfaces are designed exclusively for policy lookup operations, and packets arriving without the proper flag indicate an internal data plane communication error. This drop typically points to a software defect in the packet handoff mechanism between VPP and the security engine, rather than a configuration issue or external traffic problem.

Recommendation:

This counter should normally remain at zero. If it increments, it indicates an internal platform issue rather than a network or configuration problem. Collect the output of 'show asp drop' and 'show version' to identify the platform and software version. Check for any known defects affecting VPP-to-Lina packet handoff on your platform and software release. If the counter is incrementing actively, contact Cisco TAC with a troubleshooting bundle, as this typically requires engineering investigation of the internal data plane communication path.

Syslogs:

None

----------------------------------------------------------------

meta-expired

Packet metadata lost before transmission

This counter increments when the firewall attempts to transmit a packet but the internal packet metadata structure has been lost or invalidated. This typically occurs when packets are held in output queues (such as QoS priority queues or shaping queues) and the associated connection expires before the packet can be transmitted. The packet is dropped because the firewall can no longer determine how to process or forward it. Common scenarios include: (1) Packets queued for QoS treatment where the flow times out before the packet is dequeued and transmitted. (2) Firewall-originated traffic (such as syslog or NTP packets) on interfaces with QoS priority queuing configured, particularly on port-channel interfaces. (3) Cluster environments where packets are forwarded between cluster members but the flow has already expired on the receiving member. (4) Packets returning from external inspection (such as IDS/IPS) after the flow has timed out. (5) Attempts to inject TCP RST packets on flows that have already been torn down.

Recommendation:

Review connection timeout settings if legitimate long-lived connections are being prematurely closed—consider increasing timeout values for the affected traffic class. If this counter increments on interfaces with QoS priority queuing configured, verify that the priority-queue feature is appropriate for your deployment; on some platforms and configurations, priority queuing can cause silent packet drops for firewall-generated traffic. Check for high queue depths or shaping delays that might cause packets to remain queued longer than flow timeout values. In cluster deployments, verify that cluster control link latency is not causing forwarding delays that exceed flow timeouts. If the counter increments during normal operation without user impact, it may indicate expected cleanup of stale packets and can be considered benign. Contact Cisco TAC if the counter increments rapidly or correlates with application failures.

Syslogs:

None.

----------------------------------------------------------------

monitor-only-mode-hdr-mismatch

Monitor-only mode configuration mismatch

Packets are dropped when they return from an inspection module (SFR or CX) with a backplane header that indicates a different monitor-only mode setting than what is currently configured on the device. This occurs on ASA platforms with service modules when packets traverse the internal backplane between the ASA data plane and the inspection module. Monitor-only mode determines whether the inspection module can actively block traffic (inline mode) or only observe and log it (monitor-only mode). The mismatch typically happens during configuration changes when the ASA and the inspection module temporarily have inconsistent mode settings, or when packets queued in the inspection module are returned after a mode change has been applied.

Recommendation:

This counter usually indicates a transient condition during configuration changes between inline and monitor-only modes. If the counter increments briefly after changing the inspection mode (using commands such as 'sfr fail-open monitor-only' or 'cx fail-open'), this is expected behavior as in-flight packets are processed. If the counter continues to increment steadily during normal operation, verify that the inspection module configuration matches the ASA configuration by checking 'show running-config sfr' or 'show running-config cx' and comparing with the module's operational state using 'show module sfr details'. Persistent mismatches may indicate a communication issue between the ASA and the inspection module; check for dataplane communication errors with 'show module' and review logs for module failure messages. If the issue persists, contact Cisco TAC.

Syslogs:

323006 (Module data channel communication failure)

----------------------------------------------------------------

mp-pf-queue-full

Port Forwarding Queue to Security Services Module Is Full

This counter increments when traffic destined for a Security Services Module (SSM) such as CX or IPS cannot be queued because the internal transmission queue to the SSM is full. On ASA 5500 series platforms with an SSM installed, the port forwarding feature uses promiscuous interfaces to send copies of traffic to the SSM over the backplane for inspection or processing. When the SSM cannot process packets quickly enough, or when there is a problem with backplane communication, the queue fills and new packets are dropped. This typically indicates the SSM is overloaded, has failed, or the backplane link between the ASA and SSM is experiencing issues.

Recommendation:

Check the health and status of the Security Services Module using 'show module' and verify it is in the 'Up' state. Review SSM resource utilization (CPU, memory) to determine if the module is overloaded. If the SSM is healthy but this counter is incrementing, the traffic rate may exceed the SSM's processing capacity—consider adjusting the traffic sent to the SSM or upgrading the module. If the SSM shows as down or unresponsive, troubleshoot the module itself and the backplane connectivity. Persistent occurrences with a healthy SSM should be reported to Cisco TAC as they may indicate a software defect in the queuing mechanism.

Syslogs:

None.

----------------------------------------------------------------

mp-send-cp-fail

AnyConnect SSL VPN error notification failed

This counter increments when the security appliance cannot send an internal error notification to the control plane for an AnyConnect SSL VPN session. This typically occurs in two scenarios: (1) memory allocation failure when constructing the error message, or (2) the VPN session has already been torn down by the time the error notification is ready to be sent. The most common trigger is when Dead Peer Detection (DPD) detects a failed peer and attempts to notify the control plane, but insufficient memory or session state changes prevent the notification from being delivered. This counter represents a failure in internal communication between the data plane and control plane for AnyConnect SSL/TLS VPN tunnels, not a failure in client-facing VPN traffic.

Recommendation:

Low, intermittent increments of this counter are typically benign and indicate transient race conditions during session teardown. If this counter increments frequently or continuously, investigate system memory utilization using 'show memory' and 'show blocks'. High memory pressure can prevent internal message allocation. Check for AnyConnect session instability using 'show vpn-sessiondb detail anyconnect' and review DPD configuration with 'show run all webvpn' (look for 'anyconnect dpd-interval'). If the counter correlates with VPN service disruption or memory exhaustion, collect a troubleshooting bundle and contact Cisco TAC for analysis.

Syslogs:

None directly associated. May correlate with syslog 751003 (DPD message needed) or 718039 (dead peer detected) if DPD-related.

----------------------------------------------------------------

mp-service-inject-failed

Packet injection from service module failed

The device dropped a packet that a midpath service module (such as SSL/TLS decryption or deep packet inspection) attempted to reinject into the datapath after processing. This occurs when the service module completes inspection or decryption of a packet and tries to send it back into the normal forwarding path, but the injection operation fails. Common causes include: the original connection has already been torn down or released before the processed packet could be reinjected; internal resource exhaustion such as metadata allocation failures or work queue congestion on multi-core platforms; or invalid flow state where the upstream or downstream flow handles no longer match the packet's intended direction. This counter is most commonly seen with SSL decryption policies, particularly during high connection churn or when connections are closed while packets are still being processed by the service module.

Recommendation:

This drop is typically transient and occurs during normal operation when connections close while packets are in-flight through inspection services. If the counter increments occasionally during connection teardown, no action is required. Investigate further if the counter increments frequently or correlates with application failures: verify that SSL decryption policies are not overloading the device by checking CPU utilization and connection rates; review concurrent connection limits and consider whether the traffic load exceeds platform capacity; check for abnormal connection churn patterns that might cause race conditions between packet processing and flow teardown. If the issue persists under normal load conditions or affects production traffic, collect troubleshooting data including 'show asp drop', 'show conn', 'show service-policy', and packet captures, then contact Cisco TAC for analysis.

Syslogs:

421004

----------------------------------------------------------------

mp-svc-addr-renew-response

AnyConnect client sent address renew response instead of request

This counter increments when the security appliance receives an Address Renew Response message from an AnyConnect SSL VPN client. This represents a protocol violation in the CSTP (Cisco SSL Tunnel Protocol) communication between the client and the appliance. In normal operation, the client should send Address Renew Request messages to the appliance, and the appliance responds with Address Renew Response messages. When a client incorrectly sends a response message in the upstream direction, the appliance drops the frame because response messages are only valid in the downstream (appliance-to-client) direction. This typically indicates a software defect in the AnyConnect client or corruption of the client software.

Recommendation:

This counter indicates an AnyConnect client software error. Verify the AnyConnect client version and ensure it is a supported release. If the issue persists, try reinstalling or upgrading the AnyConnect client software on the affected endpoint. If the problem continues after client remediation, collect the AnyConnect DART bundle from the affected client and the output of 'show vpn-sessiondb detail anyconnect' from the security appliance, then contact Cisco TAC for further investigation. This is not a configuration issue and cannot be resolved through appliance configuration changes.

Syslogs:

None.

----------------------------------------------------------------

mp-svc-async-qlimit

Hardware-offloaded DTLS session exceeded async work queue limit

Packets were dropped because a hardware-offloaded DTLS session exceeded the internal work queue limit on this platform. This counter is specific to Firepower 4200 series devices (particularly FPR4245) when DTLS crypto offload is enabled for AnyConnect remote access VPN sessions. The queue limit (default 5000 packets per queue) exists to prevent memory exhaustion during very high-throughput DTLS traffic. When outbound DTLS packets are queued faster than the hardware offload engine can process them, this backpressure mechanism drops excess packets rather than consuming all available packet buffers. This typically occurs during sustained high-bandwidth file transfers or bulk data movement over a single DTLS tunnel.

Recommendation:

This counter indicates the DTLS session is exceeding the platform's hardware offload processing capacity. First, verify whether performance is actually degraded—occasional drops may not impact user experience due to TCP retransmission. If users report slowness or the counter increments rapidly: (1) Check if multiple high-bandwidth DTLS sessions are active simultaneously and consider load distribution; (2) Review the AnyConnect group policy configuration—if DTLS is not required, consider using IKEv2 instead; (3) On FTD managed by FMC, the queue depth can be increased via FlexConfig (use the 'qlimit svc' command under webvpn configuration mode); on standalone ASA, use 'qlimit svc <tx-depth> <rx-depth>' under webvpn configuration. Increasing queue depth trades memory for throughput headroom. If drops persist after tuning or occur at moderate traffic levels, contact Cisco TAC for platform-specific guidance.

Syslogs:

None.

----------------------------------------------------------------

mp-svc-bad-compress

AnyConnect SSL VPN compression engine failure

This counter increments when the device cannot compress a packet destined for an AnyConnect client over an SSL VPN tunnel. The failure occurs when compression is enabled (deflate or LZS algorithms) and the compression operation cannot complete successfully. Common causes include insufficient memory resources to perform the compression operation, internal compression engine errors, or situations where the compressed output cannot be properly formatted for transmission. This typically affects environments with high numbers of concurrent AnyConnect sessions or devices experiencing memory pressure. The affected packet is dropped and the client may experience connection instability or repeated reconnection attempts. This counter applies only to SSL VPN connections; DTLS compression failures are tracked separately.

Recommendation:

Check device memory utilization with 'show memory' to determine if memory exhaustion is contributing to compression failures. If memory is constrained, consider disabling SSL compression for AnyConnect clients using 'anyconnect ssl compression none' under the group policy or tunnel-group configuration. Note that DTLS compression can remain enabled as it uses a different compression path. If compression failures persist without memory pressure, disable compression entirely as a workaround. For production environments experiencing this issue, evaluate whether the bandwidth savings from compression justify the CPU and memory overhead, particularly on platforms with limited resources or high session counts. If this counter increments frequently alongside syslog message 722021 (unable to start compression due to lack of memory resources), compression should be disabled to restore session stability.

Syslogs:

722021

----------------------------------------------------------------

mp-svc-bad-decompress

AnyConnect DTLS compressed packet decompression failure

The firewall received a compressed data packet from an AnyConnect client over a DTLS tunnel but was unable to decompress it. This occurs when compression is enabled on the AnyConnect session (DEFLATE or LZS algorithm) and the received compressed frame is malformed, corrupted in transit, or contains invalid compression data. Common causes include: the compressed data stream contains errors that violate the compression algorithm's format, the checksum verification fails after decompression (indicating data corruption), the decompressed output would exceed available buffer space, or required compression markers are missing. This counter may also increment if the client and firewall have mismatched compression state, such as when a client sends compressed frames but the firewall's compression context is not properly initialized. The affected packet is dropped and the client may experience intermittent connectivity issues or need to retransmit.

Recommendation:

Check whether compression is intentionally enabled for AnyConnect sessions using 'show run all group-policy' and look for 'anyconnect ssl compression' or 'anyconnect dtls compression' settings. If compression is not required for your deployment, disable it globally with 'no compression anyconnect-ssl' or per group-policy with 'anyconnect ssl compression none' and 'anyconnect dtls compression none'. If compression is needed, verify that clients are running a current AnyConnect version compatible with the configured compression algorithm. Examine the client-side AnyConnect logs for compression errors or warnings. If drops are frequent and persistent for specific clients, suspect network path issues causing packet corruption—test with compression disabled to isolate. For sporadic drops across many clients, check firewall memory utilization with 'show memory'; memory pressure can cause decompression buffer allocation failures. If the issue began after an upgrade, review known defects related to AnyConnect compression for your software version. Contact Cisco TAC if drops persist after disabling compression or if you require compression for bandwidth optimization but cannot resolve the decompression failures.

Syslogs:

None directly associated. Related syslog 722021 (severity 3) may appear if decompression fails due to memory resource exhaustion.

----------------------------------------------------------------

mp-svc-bad-framing

AnyConnect SSL VPN tunnel received malformed CSTP frame

The security appliance dropped a packet from an AnyConnect VPN client (or from the appliance to the client) because the CSTP (Cisco SSL Tunnel Protocol) frame header was malformed. CSTP is the protocol used to encapsulate traffic inside AnyConnect SSL VPN tunnels. This drop occurs when the frame header contains invalid start-of-header markers, an incorrect protocol version number, or an invalid reserved field value. The most common cause is a version mismatch between the AnyConnect client software and the ASA/FTD software, where the client is using an older or incompatible CSTP protocol version. Less commonly, this can indicate packet corruption in transit or a software defect in either the client or the appliance.

Recommendation:

Check syslog message 722017, which displays the exact header field values that failed validation. Verify that the AnyConnect client version is compatible with your ASA/FTD software version—refer to the AnyConnect and ASA/FTD compatibility matrix in Cisco documentation. If clients are running outdated software, upgrade them to a compatible version. If the issue occurs with up-to-date clients, check for network conditions that might corrupt SSL VPN traffic (such as middleboxes performing deep packet inspection or SSL interception). Occasional drops may be benign (transient network issues), but persistent drops for a specific user or client version indicate a compatibility or configuration problem. If drops persist after verifying version compatibility, collect packet captures and contact Cisco TAC.

Syslogs:

722017, 722037

----------------------------------------------------------------

mp-svc-bad-length

AnyConnect SSL VPN packet length mismatch

The firewall received an AnyConnect SSL VPN packet where the length specified in the protocol header does not match the actual packet size. AnyConnect uses an internal protocol that includes a length field in each frame; when this field is inconsistent with the received data, the packet is dropped to prevent processing corrupted or malformed traffic. This can occur in either direction: from the AnyConnect client to the firewall, or from the firewall to the client. Under normal operation, this counter should remain at zero. Non-zero values typically indicate one of three conditions: a version incompatibility between the AnyConnect client and the firewall software, network corruption affecting the SSL VPN tunnel traffic, or a software defect in either the client or the firewall.

Recommendation:

First, verify that the AnyConnect client version is compatible with the firewall software version; consult the AnyConnect and firewall compatibility matrix. Check for any network devices between the client and firewall that might be corrupting or fragmenting SSL traffic, such as proxies, load balancers, or deep packet inspection devices. Review syslog messages 722037 (client-to-firewall drops) and 722016 (general framing errors) to identify which users or sessions are affected. If the issue persists with compatible versions and no intermediate devices, or if it affects multiple clients, contact Cisco TAC with the output of 'show asp drop' and relevant syslogs, as this may indicate a software defect requiring investigation.

Syslogs:

722037, 722016

----------------------------------------------------------------

mp-svc-compress-error

AnyConnect VPN compression failure

This counter increments when the security appliance encounters an error while attempting to compress data for an AnyConnect VPN (formerly SVC) tunnel. Compression errors occur when the compression engine fails to process a packet, typically due to memory allocation failures, internal compression library errors, or invalid compression state. The affected packet is dropped and the tunnel may attempt to reset compression or continue without compression for subsequent packets. This applies to both SSL (TLS) and DTLS AnyConnect connections when compression is enabled (LZS or DEFLATE algorithms). The counter fires during outbound data transmission when packets are queued for compression but the compression operation returns a failure status.

Recommendation:

Check memory availability on the device using 'show memory' and 'show processes memory'. If memory is low, consider reducing the load, disabling compression for AnyConnect tunnels ('anyconnect ssl compression none' and 'anyconnect dtls compression none' in group policy or global configuration), or upgrading to a platform with more resources. Review syslog message 722021 which indicates memory exhaustion during compression initialization. If drops are frequent but memory is adequate, this may indicate a software defect—collect 'show compression' statistics, 'show webvpn anyconnect' output, and contact Cisco TAC. Note that compression is most beneficial on low-bandwidth links; on high-speed connections the CPU overhead may outweigh bandwidth savings. Verify the AnyConnect client and ASA/FTD software versions are compatible and up-to-date, as compression bugs have been resolved in newer releases.

Syslogs:

722021, 722037

----------------------------------------------------------------

mp-svc-decompress-error

AnyConnect SSL VPN decompression failure

This counter increments when the security appliance fails to decompress data received from an AnyConnect SSL VPN client that has compression enabled. Decompression can fail for several reasons: the compressed data stream is corrupted or malformed, the decompressed payload fails checksum validation, internal buffer allocation fails due to memory pressure, or the compression algorithm (DEFLATE or LZS) encounters an invalid data structure. This typically occurs on AnyConnect SSL VPN sessions where compression has been enabled via the 'anyconnect ssl compression' command with either 'deflate' or 'lzs' algorithms. When decompression fails, the affected packet is dropped and the VPN session may be terminated or reset to recover the compression state.

Recommendation:

Check for syslog 722037 to identify which user and group policy are affected. Review memory utilization on the security appliance using 'show memory' and 'show blocks'—sustained memory pressure can cause buffer allocation failures during decompression. If the issue is persistent for specific clients, verify that both the AnyConnect client and security appliance are running compatible software versions. Consider disabling SSL compression for the affected group policy using 'anyconnect ssl compression none' if the problem persists, as compression provides diminishing returns on modern networks and can introduce stability issues under certain conditions. Occasional occurrences (accompanied by syslog 722027 indicating automatic recovery) may be benign and caused by transient network conditions. If drops are frequent or affect multiple users, collect a packet capture of the SSL VPN session and contact Cisco TAC for analysis.

Syslogs:

722037, 722027, 722029

----------------------------------------------------------------

mp-svc-delete-in-progress

AnyConnect connection received data during session teardown

This counter increments when the firewall receives a packet for an AnyConnect SSL VPN connection that is in the process of being deleted. AnyConnect sessions (formerly called SVC - Secure VPN Client) are torn down for several reasons: user disconnect, idle timeout, administrative logoff (vpn-sessiondb logoff command), session limit enforcement, or high-availability failover events. During the brief window between when deletion begins and when the connection is fully removed from the data plane, any in-flight packets arriving for that connection are dropped and counted here. This is normal behavior during session teardown, as packets may still be in transit when the control plane initiates the deletion process.

Recommendation:

Low, sporadic increments are expected during normal AnyConnect session lifecycle events and require no action. Investigate if this counter increments rapidly or in large volumes, which may indicate: (1) network connectivity problems causing clients to disconnect and reconnect frequently, (2) aggressive timeout values forcing premature session teardowns, or (3) on virtual platforms (ASAv), potential performance issues related to SVC module flow control (see related counter mp-svc-flow-control). Review AnyConnect session logs (syslogs 113019, 722033, 722034) to identify the teardown triggers. If sessions are terminating unexpectedly, check idle-timeout and session-timeout settings in the group policy, verify network stability between clients and the firewall, and confirm that license limits are not forcing session preemption.

Syslogs:

113019 (session disconnect with reason), 722033 (SVC connection established), 722034 (SVC reconnection attempt)

----------------------------------------------------------------

mp-svc-flow-control

AnyConnect VPN tunnel queue limit exceeded

The appliance dropped a packet because the internal transmit queue for an AnyConnect SSL VPN or DTLS VPN tunnel reached its limit. This flow control mechanism prevents the appliance from overwhelming a tunnel that cannot accept data quickly enough. The counter increments when packets destined for (most common) or arriving from (rare) an AnyConnect client exceed the tunnel's buffering capacity. Common triggers include high-latency network paths between the appliance and client, client devices with limited processing capacity or network bandwidth, virtual appliances (ASAv) under resource pressure, or sustained high-volume traffic through a single VPN session. DTLS tunnels may be more susceptible than TLS tunnels due to differences in transport-layer flow control.

Recommendation:

Use packet capture with 'capture <name> type asp-drop mp-svc-flow-control' to determine the traffic direction. If drops occur on traffic TO the client (most common): verify the client's network path for high latency or packet loss, check client device CPU and memory utilization, confirm the client's local network bandwidth is adequate, and review whether the client is behind additional NAT or firewall devices introducing delays. If drops occur on traffic FROM the client (rare): check appliance CPU and memory utilization, review for resource contention on virtual platforms, and verify the appliance is not oversubscribed with concurrent VPN sessions. For persistent drops on virtual platforms, consider increasing allocated CPU or memory resources. For DTLS-specific drops with low client counts, evaluate whether disabling DTLS (using 'anyconnect ssl dtls none' under the group policy) improves performance. Contact Cisco TAC if drops persist after addressing network latency and resource constraints, or if drops occur with low traffic volumes on adequately provisioned hardware.

Syslogs:

None.

----------------------------------------------------------------

mp-svc-invalid-mac

AnyConnect SSL VPN packet missing L2 MAC header during reinjection

This counter increments when the security appliance processes a decrypted AnyConnect SSL VPN packet but cannot find the Layer 2 MAC header needed to reinject the packet into the normal forwarding path. After an SSL VPN client sends encrypted traffic, the appliance decrypts it, decompresses it if needed, and must reconstruct the original Ethernet frame by restoring the L2 header that was removed during SSL encapsulation. This drop occurs when the internal pointer to that MAC header is unexpectedly missing from the packet buffer, preventing successful reinjection. This typically indicates a software defect in packet buffer management during the SSL VPN decryption and decompression pipeline.

Recommendation:

This counter indicates an internal software error and should not occur during normal operation. If you observe this counter incrementing, collect the output of 'show asp drop', 'show vpn-sessiondb detail anyconnect', and 'show tech-support' and contact Cisco TAC. Note the AnyConnect client version in use and whether compression is enabled in the group policy. As a temporary workaround, you may try disabling compression for the affected group policy using 'no compression' under the group-policy webvpn configuration, though this addresses a symptom rather than the root cause.

Syslogs:

None.

----------------------------------------------------------------

mp-svc-invalid-mac-len

Invalid Layer 2 header length in AnyConnect SSL VPN decrypted packet

This counter increments when the security appliance detects an invalid Layer 2 MAC header length while processing a decrypted AnyConnect SSL VPN packet. After decrypting SSL VPN traffic, the appliance must reconstruct the original Ethernet frame by removing the SSL tunnel protocol header and repositioning the MAC header. During this process, the appliance validates that the calculated MAC header length matches one of the standard Ethernet frame types (standard Ethernet, 802.1Q VLAN-tagged, 802.3, or Command Metadata-tagged frames). This drop occurs when the calculated header length does not match any expected value, indicating the packet structure is malformed or corrupted. This validation is part of the security checks that prevent malformed packets from being reinjected into the data path after decryption.

Recommendation:

This counter typically indicates a software error or packet corruption during AnyConnect SSL VPN processing. Check for: (1) AnyConnect client version compatibility—ensure clients are running a supported version that matches the appliance software version, (2) network issues between the client and appliance that could corrupt SSL VPN packets in transit, (3) MTU mismatches or fragmentation issues on the SSL VPN tunnel. If drops are persistent and affecting VPN connectivity, collect the output of 'show asp drop' and 'show vpn-sessiondb detail anyconnect' along with packet captures, and contact Cisco TAC. Isolated occurrences may be benign and caused by transient network conditions, but sustained drops indicate a problem requiring investigation.

Syslogs:

None

----------------------------------------------------------------

mp-svc-invalid-src-addr

AnyConnect SSL VPN packet dropped due to source IP address mismatch

This counter increments when the security appliance receives a decrypted packet from an AnyConnect SSL VPN client where the inner (encapsulated) source IP address does not match the IP address assigned to that VPN session. After the SSL VPN tunnel decrypts a packet, the appliance validates that the source IP in the inner packet header matches the address that was assigned to the client during session establishment (via local pool, DHCP, or AAA). This validation prevents an authenticated VPN user from crafting packets that spoof another user's IP address within the tunnel. The check applies to both IPv4 and IPv6 traffic and occurs during packet reinjection into the upstream data path after decompression and decryption.

Recommendation:

This counter indicates a security violation attempt or a serious client-side software error. In normal operation, legitimate AnyConnect clients always use their assigned IP address as the source for all tunneled traffic, so this counter should remain at zero. If this counter increments, investigate immediately: (1) Identify the affected VPN session and user from concurrent connection logs or session manager output. (2) Check whether the client device is compromised or running modified VPN software. (3) Review AnyConnect client version and integrity—outdated or tampered clients may exhibit this behavior. (4) Examine firewall logs and packet captures (if available) to determine if this is an isolated incident or part of a broader attack pattern. This validation was added to address a known security vulnerability (CSCwd98316); increments of this counter represent blocked exploit attempts or client malfunctions that warrant investigation. Contact Cisco TAC if the issue persists or if you suspect an active security incident.

Syslogs:

None.

----------------------------------------------------------------

mp-svc-no-channel

SSL VPN session missing interface channel for packet reinjection

This counter increments when the firewall cannot reinject traffic for an SSL VPN (AnyConnect or clientless) session because the interface or channel associated with the VPN session is unavailable. This occurs in two scenarios: when decrypted inbound VPN traffic cannot be reinjected into the network after decryption, or when outbound traffic destined for a VPN client cannot be sent through the tunnel. The most common cause is stale VPN session state remaining in the datapath after a user disconnects—the VPN session database shows no active session, but routing and datapath entries persist. This is particularly seen with AnyConnect sessions using static IP address assignment via RADIUS or ISE authorization profiles. Less commonly, it occurs when an interface is administratively shut down or experiences a link failure while active VPN sessions are using it.

Recommendation:

First, verify whether active VPN sessions exist using 'show vpn-sessiondb detail anyconnect' and compare against the IP addresses experiencing drops. If sessions appear active but traffic fails, check the interface status with 'show interface' for the VPN termination interface. If no active sessions exist but drops continue, this indicates stale datapath state—a known issue fixed in ASA 9.16.4.82, 9.18.4.53, 9.20.3.16, and later releases. For affected versions, clearing the stale state requires reloading the device (both units in a high-availability pair). In rare cases where an interface was intentionally shut down, re-enable it with 'no shutdown'. If drops occur without stale sessions or interface issues, contact Cisco TAC with the output of 'show asp table classify' and 'show vpn-sessiondb' for further analysis.

Syslogs:

None.

----------------------------------------------------------------

mp-svc-no-fragment

SSL VPN tunnel packet fragmentation failed

This counter increments when a packet destined for an SSL VPN (AnyConnect) tunnel cannot be fragmented to fit within the configured tunnel MTU. Two conditions trigger this drop: (1) the original packet has the Don't Fragment (DF) bit set and the group policy is not configured to ignore it, preventing fragmentation even though the packet exceeds the tunnel MTU; or (2) the device cannot allocate sufficient memory buffers to create the fragmented packets, typically occurring during periods of high memory utilization or resource exhaustion. The tunnel MTU is reduced from the physical interface MTU due to SSL/TLS encapsulation overhead (typically 100-200 bytes), so packets that fit on the physical interface may still require fragmentation when sent through the tunnel.

Recommendation:

If drops occur consistently for specific traffic: verify the tunnel MTU configuration using 'show vpn-sessiondb detail anyconnect' and consider increasing it with the 'anyconnect mtu' command in the group policy (maximum 1406 bytes for SSL, 1500 for DTLS). If the DF bit is causing drops, enable 'anyconnect df-bit-ignore enable' in the group policy webvpn configuration to allow fragmentation of DF-marked packets. If drops occur sporadically or during high load: check overall system memory utilization with 'show memory' and 'show blocks'; reduce concurrent VPN sessions, disable unnecessary features, or add memory if consistently near capacity. Review application behavior—some applications set DF inappropriately; enabling DF-bit-ignore resolves this. If drops persist after MTU tuning and memory is adequate, contact Cisco TAC with 'show asp drop' output and memory statistics.

Syslogs:

None.

----------------------------------------------------------------

mp-svc-no-mac

AnyConnect VPN packet missing L2 header during reinject

This counter increments when the security appliance attempts to reinject a decrypted AnyConnect (SSL VPN) packet back into the datapath but cannot locate the Layer 2 MAC header in the internal packet buffer. After an AnyConnect client sends encrypted traffic through the SSL VPN tunnel, the appliance decrypts the packet and must reconstruct the Ethernet frame before forwarding it. This drop occurs when the internal buffer pointer to the MAC header is unexpectedly null, preventing the appliance from properly rebuilding the frame. This condition indicates an internal packet-processing error during the decryption and reinject workflow for AnyConnect sessions.

Recommendation:

This counter indicates a software defect in the AnyConnect packet-processing path. If this counter increments, collect the output of 'show vpn-sessiondb detail anyconnect', 'show asp drop', and 'show interface' to identify which AnyConnect sessions are affected. Document the AnyConnect client version, tunnel protocol in use (SSL or DTLS), and any compression settings configured on the group policy. Contact Cisco TAC with this information and request correlation with any known defects affecting AnyConnect packet buffer handling during decryption. This is not a configuration issue and cannot be resolved through policy changes.

Syslogs:

None.

----------------------------------------------------------------

mp-svc-no-prepend

Insufficient buffer headroom for MAC header after VPN decompression

This counter increments when an AnyConnect or SSL VPN (SVC) session with compression enabled receives a compressed packet from the tunnel, successfully decompresses it, but cannot reinject the decompressed packet into the network because the packet buffer lacks sufficient space before the data to prepend the required Layer 2 (MAC) header. This is a buffer allocation issue in the VPN compression data path. The condition typically occurs when the decompression operation produces a packet buffer without adequate headroom reserved for downstream processing. Compression is enabled via the 'compression' command under group-policy or username webvpn configuration.

Recommendation:

This indicates a software defect in buffer management for the VPN compression subsystem. The decompression engine should allocate buffers with sufficient headroom for Layer 2 headers, but has failed to do so. Collect the output of 'show vpn-sessiondb detail anyconnect', 'show asp drop', and 'show compression' to document which sessions are affected and whether compression is actively in use. If this counter is incrementing, contact Cisco TAC with a troubleshooting bundle captured during active VPN sessions. As a temporary workaround, disabling compression on affected group policies or user accounts ('no compression' under webvpn configuration mode) will prevent the condition, though it may impact bandwidth utilization on low-speed links.

Syslogs:

None.

----------------------------------------------------------------

mp-svc-no-session

SSL VPN tunnel session not available

The security appliance dropped a packet because it could not find a valid AnyConnect or legacy SSL VPN Client session to process the traffic. This occurs when the device attempts to encrypt outbound traffic destined for a VPN client, or decrypt inbound traffic from a VPN client, but the associated tunnel session is missing, not fully established, or being torn down. Common scenarios include: traffic arriving immediately after tunnel establishment but before the session is fully initialized (a brief race condition during connection setup), the tunnel session being deleted while flows still reference it, or internal state corruption where the session pointer becomes invalid. For UDP-based applications over SSL VPN, this drop may occur if the client sends traffic within the first few seconds of tunnel establishment before all session state is synchronized.

Recommendation:

If this counter increments occasionally during tunnel establishment and clients successfully connect, the drops are typically benign—they represent transient packets that arrived during the brief window between connection acceptance and full session initialization. Clients will retransmit, and subsequent traffic will succeed. If the counter increments persistently for established sessions or prevents successful VPN connectivity, investigate: verify the tunnel is fully established using 'show vpn-sessiondb detail anyconnect'; check for session database inconsistencies or resource exhaustion; review logs for authentication or authorization failures that might prevent session creation; and examine whether rapid connection/disconnection cycles are causing stale flow references. If UDP applications (such as VoIP) fail immediately after connecting, consider adding a brief delay on the client side before sending traffic to allow full session establishment. Persistent drops with no successful connectivity indicate a software defect and should be reported to Cisco TAC with session details and packet captures.

Syslogs:

722033 (First SVC connection established)

----------------------------------------------------------------

mp-svc-session-frag-fail

SSL VPN tunnel fragmentation error notification failed

This counter increments when the security appliance cannot schedule the generation of an ICMP Destination Unreachable (Fragmentation Needed) error message for SSL VPN (AnyConnect or legacy SVC) tunnel traffic. This occurs when a packet destined for an SSL VPN tunnel exceeds the configured tunnel MTU and requires fragmentation, but the fragmentation operation fails and the system is unable to queue asynchronous work to notify the original sender. The failure to schedule this notification work typically indicates resource exhaustion, such as full asynchronous work queues or memory pressure during periods of high SSL VPN session activity.

Recommendation:

This counter should remain at zero during normal operation. If this counter increments, investigate system resource utilization on the security appliance, particularly during periods of high SSL VPN session load. Check CPU utilization, memory usage, and the number of active SSL VPN sessions. Review SSL VPN tunnel group MTU settings to ensure they are appropriately configured for the network path. If the counter increments frequently or is accompanied by SSL VPN connectivity issues or system instability, collect a technical support bundle and contact Cisco TAC for analysis, as this may indicate underlying resource exhaustion or a software issue requiring further investigation.

Syslogs:

None.

----------------------------------------------------------------

mp-svc-session-lock-failure

SSL VPN session lock acquisition failure

This counter increments when the system cannot acquire an internal lock on an SSL VPN (AnyConnect/Secure Client) session while processing tunnel traffic. The lock protects session data structures during concurrent access on multicore platforms. The failure occurs when processing encrypted traffic from the VPN client (upstream data, DTLS packets, or decompressed packets being reinjected into the data path). Lock acquisition can fail if the lock is held indefinitely by another process, the session structure is corrupted, or the lock owner reference is invalid. This condition indicates an internal software error rather than a configuration or capacity issue.

Recommendation:

This counter should remain at zero during normal operation. Any increment indicates a software defect that may lead to dropped VPN traffic or system instability. If this counter increments, collect the output of 'show vpn-sessiondb detail anyconnect', 'show asp drop', and 'show tech-support' and contact Cisco TAC immediately. Do not attempt configuration changes to resolve this issue. If the counter is incrementing frequently, consider temporarily reducing the number of concurrent AnyConnect sessions or disabling compression on the affected tunnel group as a workaround until the underlying software issue is resolved.

Syslogs:

None.

----------------------------------------------------------------

mp-svc-unknown-type

AnyConnect client sent unrecognized protocol frame type

The security appliance received an AnyConnect packet containing a frame type identifier that is not recognized by the current software version. AnyConnect uses the CSTP (Cisco SSL Tunnel Protocol) to encapsulate VPN traffic, and each frame includes a type field that identifies its purpose (data, keepalive, control message, etc.). When the appliance encounters a frame type it does not understand, it drops the packet and increments this counter. This typically occurs when an AnyConnect client is running a newer version than the security appliance and attempts to use protocol features or frame types that were introduced after the appliance software was released. The mismatch prevents the appliance from properly processing the frame. Syslog message 722015 is generated when this condition occurs, identifying the user, group, IP address, and the numeric frame type value that was not recognized.

Recommendation:

Verify that the AnyConnect client version is compatible with the security appliance software version. Check the AnyConnect and ASA/FTD compatibility matrix in the release notes to ensure the client version is supported. If clients are running a newer AnyConnect version than recommended for your appliance software, either upgrade the security appliance to a version that supports the newer client features, or downgrade the AnyConnect clients to a compatible version. Review syslog message 722015 to identify which users and client versions are affected. If the counter increments occasionally and does not impact connectivity, it may indicate clients attempting to use optional features that gracefully fall back when unsupported. However, persistent or high-volume drops may indicate a systematic version mismatch that requires remediation. Ensure that AnyConnect client deployment policies enforce compatible versions for your infrastructure.

Syslogs:

722015

----------------------------------------------------------------

nat-64-or-46-conversion-fail

NAT64 or NAT46 Protocol Translation Failure

The firewall attempted to translate a packet between IPv4 and IPv6 address families using NAT64 (IPv6-to-IPv4) or NAT46 (IPv4-to-IPv6) but the translation failed. This occurs when the device is configured for dual-stack NAT to enable communication between IPv4-only and IPv6-only networks. The drop happens either during the packet header conversion process or when validating the translated flow. Common causes include misconfigured NAT rules where the translated addresses do not match the expected IP version, insufficient packet buffer space to accommodate the larger IPv6 header (40 bytes versus 20 bytes for IPv4), or MTU mismatches between the ingress and egress interfaces. On virtual platforms (FTDv, ASAv), buffer size constraints can trigger this drop during return traffic after successful forward translation. The counter may also increment when the NAT rule specifies translation between IP versions but the flow's translated addresses end up with mismatched IP families (for example, one address translated to IPv6 while the other remains IPv4).

Recommendation:

Verify that NAT64 or NAT46 rules are configured correctly with appropriate IPv6 prefix lengths: for NAT64, the destination prefix should be /96 or shorter (or /64 for net-to-net mapping); for NAT46, the translated source prefix must meet minimum length requirements based on the mapping type. Check that both source and destination interfaces support the required IP versions and that MTU settings accommodate the protocol translation overhead. Use 'show xlate' to confirm that address translations are producing consistent IP version pairs. If the issue occurs on virtual platforms during return traffic, consider adding a prefilter rule with fastpath action for the affected traffic as a workaround, or verify that the platform has sufficient buffer resources allocated. Review 'show asp drop' frame details to determine whether the failure occurred during header translation or flow validation. If embedded ICMP error messages are involved, ensure that the embedded IP addresses conform to RFC 6052 formatting for NAT64. For persistent issues, collect packet captures on both interfaces and 'debug nat' output to identify the exact point of translation failure.

Syslogs:

None.

----------------------------------------------------------------

nat-cluster-input

Invalid cluster NAT query parameter

The device dropped an internal cluster communication message used to coordinate Network Address Translation between cluster members because the message contained invalid parameters. This occurs when a cluster member receives a NAT translation request, untranslation request, or VPN encryption redirect with either a missing or invalid interface reference, or an IP address with an unrecognized version field (neither IPv4 nor IPv6). These messages are exchanged between cluster members when one member needs another to perform NAT lookups or allocate translation resources. The drop protects against processing malformed cluster control messages that could lead to incorrect NAT behavior.

Recommendation:

This counter typically indicates a software defect in cluster message construction or memory corruption affecting cluster control traffic. Occasional increments during cluster membership changes or high load may be transient, but sustained or frequent increments warrant investigation. Verify all cluster members are running identical software versions and that the cluster control link (CCL) is stable with no packet corruption. Check for memory errors or hardware issues on the affected units. Collect 'show asp drop' output from all cluster members to identify which unit is receiving the invalid messages. If the counter increments persistently, capture cluster control link traffic and contact Cisco TAC with the troubleshooting bundle from all cluster members.

Syslogs:

None

----------------------------------------------------------------

nat-cluster-invalid-unxlate-redirect

Cluster member received redirect for NAT pool it does not own

A cluster member received a packet redirected from another member for reverse NAT translation (untranslation), but the local member does not own the PAT pool for the translated address and port in the packet. This indicates that pool ownership information is temporarily out of sync between cluster members. The drop prevents forwarding loops that could otherwise create packet storms between members. This counter typically increments during cluster membership changes such as member failures, rejoins, or when the cluster master redistributes PAT pool ownership across members. It can also occur when a director flow exists on one member while the actual connection owner flow exists on another member, causing return traffic to be redirected to the wrong member.

Recommendation:

Brief increments during cluster member failures or rejoins are expected and self-correcting—the cluster master automatically sends pool ownership updates to resynchronize members. Monitor the counter: if it increments continuously during stable cluster operation (no membership changes), this indicates a pool synchronization problem that may require further investigation. Check cluster health and verify all members show consistent pool ownership with 'show nat pool cluster'. If drops persist without topology changes, collect troubleshooting data and contact Cisco TAC.

Syslogs:

None.

----------------------------------------------------------------

nat-cluster-pool-update-fail

Cluster control node failed to send NAT pool ownership update to data node

This counter increments when the cluster control (master) node detects that a data node has stale or incorrect NAT pool ownership information and attempts to send a corrective update, but the update message fails to transmit. This occurs during return traffic processing when a data node forwards a packet to the master for untranslation, but the data node's view of which cluster member owns specific NAT pool port blocks is out of sync with the master's current assignment. The master attempts to send the correct ownership mapping to prevent future misdirected packets, but the send operation fails—typically due to insufficient cluster messaging buffers. The packet that triggered the update is dropped to prevent forwarding loops. This situation is most common after cluster membership changes (nodes joining or leaving), during NAT pool rebalancing operations, or when the system is under memory pressure.

Recommendation:

Check system memory and cluster messaging buffer availability. Use 'show memory' to verify free memory is not critically low. Monitor the 'show asp drop' output for the 'SEC_NAT_SEND_NO_BUFFER' counter—if this counter is also increasing, the root cause is cluster message buffer exhaustion. If memory is adequate but drops persist, verify cluster health with 'show cluster info' and check for frequent membership changes or flapping cluster links. Temporary drops during cluster membership events (node join/leave) are expected and typically self-correct once ownership updates complete. If drops are sustained outside of membership changes, investigate whether NAT pool configurations use overlapping IP ranges across multiple pools on the same interface, as this can trigger excessive ownership synchronization traffic. Consider simplifying NAT pool configurations to use non-overlapping address ranges. If the issue persists with adequate resources and stable cluster membership, contact Cisco TAC for further analysis.

Syslogs:

None

----------------------------------------------------------------

nat-host-pb-limits-reached

NAT translation failed - per-host port block limit reached

The firewall dropped a packet because it could not create a new translation for a host that has already reached the maximum number of port blocks allowed per host. This counter applies when port block allocation is enabled for carrier-grade NAT deployments. Port block allocation assigns contiguous blocks of ports (default 512 ports per block) to each internal host rather than individual ports. By default, each host can receive up to 4 port blocks per protocol. When a host exhausts all ports in its allocated blocks and has already reached the maximum block limit, new connection attempts from that host are dropped and this counter increments. The associated syslog 305016 identifies the specific host and PAT pool involved.

Recommendation:

Check the current port block allocations using 'show local-host' to identify which hosts have reached their limits. If legitimate hosts are hitting the limit due to high connection volume, increase the per-host limit using 'xlate block-allocation maximum-per-host <number>' (range 1-128, default 4). Alternatively, increase the block size using 'xlate block-allocation size <number>' (range 64-4096, default 512) to provide more ports per block. Verify your NAT rule configuration - if using 'nat (any,any)' with block-allocation, consider changing to specific interfaces as this can cause inefficient block allocation (see defect CSCwa55562). Monitor 'show nat pool' to check overall pool utilization. If drops persist and configuration changes are not feasible, expand the PAT pool address range to distribute load across more IPs. This counter is expected in environments with very high connection density per host; if it occurs frequently with low connection counts, investigate for potential misconfigurations or defects.

Syslogs:

305016

----------------------------------------------------------------

nat-no-xlate-to-pat-pool

Inbound Connection to PAT Pool Without Translation

Inbound traffic arrived destined to an IP address and port that is part of a dynamic PAT pool, but no active translation exists for that destination. Dynamic PAT pools are designed for outbound connections only—they create temporary port mappings when internal hosts initiate connections to the outside. When return traffic arrives for an active outbound connection, the device uses the existing translation to route packets back to the original internal host. However, when unsolicited inbound traffic arrives to a PAT pool address without a corresponding active translation, the device has no way to determine where to forward the packet and drops it. This is expected behavior for dynamic PAT. This drop is most commonly seen in three scenarios: (1) legitimate inbound connection attempts to a PAT pool IP that require static PAT configuration instead, (2) return traffic arriving after the original outbound translation has already timed out, or (3) in cluster deployments, when PAT pool ownership information becomes inconsistent between cluster members, causing one node to receive return traffic for a translation owned by a different node.

Recommendation:

First, determine whether this traffic represents legitimate inbound access attempts or return traffic for outbound connections. For legitimate inbound services (web servers, mail servers, etc.), configure static PAT to create a permanent port mapping instead of relying on dynamic PAT pools. If the drops represent return traffic for outbound connections, verify that NAT timeout values are appropriate for your traffic patterns—very short timeouts may cause translations to expire before all return packets arrive. In cluster deployments, this drop often indicates PAT pool ownership synchronization issues: check that all cluster members show consistent pool ownership with 'show nat pool cluster' and verify that port-block allocation is balanced across nodes. After cluster membership changes (node joins, leaves, or master election), allow time for pool ownership to resynchronize. If drops persist in a cluster, verify that dynamic interface PAT rules do not overlap with management or cluster control interfaces. For clusters experiencing persistent issues after node rejoins, removing and re-adding nodes sequentially (one at a time) rather than simultaneously can prevent ownership table corruption. If drops occur immediately after NAT configuration changes, a device reload may be required to fully clear stale translation state.

Syslogs:

None

----------------------------------------------------------------

nat-rpf-failed

NAT Reverse Path Check Failed

The firewall dropped a connection attempt because the forward and reverse traffic flows would use different NAT policies, or because traffic attempted to reach a translated host using its original (untranslated) address instead of its mapped address. During connection setup, the firewall performs a reverse path check to ensure that both directions of a connection use the same NAT policy. This check fails when: (1) a NAT rule translates traffic from interface A to interface B, but no corresponding rule exists to handle the reverse direction from B to A, or (2) a host on the same network as a NAT-translated server attempts to connect using the server's real IP address instead of its translated address. This is expected behavior that enforces consistent, stateful NAT translation.

Recommendation:

If the drops are unintended, verify your NAT configuration. For bidirectional communication, ensure that NAT rules are symmetric—if you translate traffic from interface A to B, configure an appropriate rule for traffic from B to A. When connecting to a translated host from a different interface, always use the mapped (translated) address, not the real address. Check 'show nat detail' to review your NAT policy and hit counts. If applications embed IP addresses in their payload (such as FTP, SIP, or H.323), enable the appropriate inspection engine with 'inspect' commands to rewrite embedded addresses. Review syslog messages 305005 (no translation group found) or 305013 (asymmetric NAT rules) for details about which connections are being dropped, including source and destination addresses. If drops occur only for specific applications, the issue may be asymmetric NAT rules or missing application inspection.

Syslogs:

305005, 305013

----------------------------------------------------------------

nat-xlate-failed

NAT Translation Creation Failed

The device was unable to create a Network Address Translation (NAT) entry for a packet that matched a NAT policy. This counter increments when the internal translation creation process fails for reasons other than address pool exhaustion. Common causes include: no matching NAT rule for the traffic (the packet requires translation but no configured NAT policy applies to the source/destination pair); configuration conflicts such as multiple overlapping dynamic PAT rules using the same translated addresses with different interface specifications; in cluster deployments, failure to allocate port blocks when both the local member and the cluster master are unable to provide translation resources; or internal resource constraints during the translation setup process. Unlike pool exhaustion drops, these failures typically indicate a configuration issue or a transient cluster synchronization problem rather than depletion of available translated addresses.

Recommendation:

Check the NAT configuration to ensure a rule exists that matches the dropped traffic's source and destination addresses and interfaces. Use 'show nat detail' to verify which NAT rules are configured and their hit counts. Review the associated syslog messages (305005, 305006) which provide specific details about the failure—syslog 305005 indicates no NAT rule matched the traffic, while 305006 indicates a rule matched but translation creation failed. If multiple dynamic PAT rules exist, verify they do not use overlapping translated IP ranges with different interface specifications, as this can cause translation creation failures. In cluster deployments, check that port block allocation is functioning correctly across all members using 'show nat pool' and verify cluster health with 'show cluster info'. If the drops are transient and cluster-related, they may resolve automatically as port blocks are redistributed. For persistent issues, enable 'debug nat' (use cautiously in production) to see detailed translation creation attempts, or collect a packet capture and troubleshooting bundle for TAC analysis.

Syslogs:

305005, 305006, 305009, 305010, 305011, 305012

----------------------------------------------------------------

nat-xlate-pool-exhausted

NAT translation failed - pool exhausted

The device could not create a new address translation because the configured NAT pool has run out of available resources. This occurs when attempting dynamic NAT or PAT (Port Address Translation) and all IP addresses or ports in the pool are already in use by active connections. The counter increments when the pool exhaustion check fails during translation creation, before attempting to allocate a specific address or port. In cluster deployments, this can occur on individual members when their portion of the pool is exhausted, even if other members have capacity. With port block allocation enabled, this counter may increment when port blocks are exhausted even though individual ports remain available in the pool. For interface PAT configurations, exhaustion occurs when all ephemeral ports on the interface address are consumed.

Recommendation:

Use 'show nat pool' to view current pool utilization and identify which pools are exhausted. Check 'show xlate' to see active translations consuming pool resources. If the pool is legitimately exhausted, expand the NAT pool by adding more IP addresses or increase connection timeouts to free resources faster. For PAT exhaustion, verify that timeout values are appropriate for your traffic patterns - overly long timeouts can cause port exhaustion. In cluster environments, verify that pool resources are properly distributed across members and check for asymmetric load. If using port block allocation, consider adjusting the block size or disabling block allocation if not required for your deployment. Review syslog messages 305005, 305006, 305009-305012, and 202010 for additional context about which specific translations are failing. If pool utilization appears low but drops persist, this may indicate a software issue - collect 'show tech-support' and contact Cisco TAC.

Syslogs:

202010, 305005, 305006, 305009, 305010, 305011, 305012

----------------------------------------------------------------

natt-keepalive

NAT-T Keepalive Message

This counter increments when the device receives and silently discards an IPsec NAT Traversal (NAT-T) keepalive packet on UDP port 4500. NAT-T keepalives are single-byte UDP packets (typically 0xFF) sent periodically by IPsec peers to maintain NAT or PAT session state in intermediate network devices between the peer and this device. These keepalives prevent the NAT mapping from timing out and breaking the IPsec tunnel. The device intentionally drops these packets after recognizing them because they serve only to refresh NAT state and require no further processing. This counter is expected to increment regularly on any IPsec site-to-site or remote access VPN tunnel where NAT-T is negotiated, which occurs automatically when IKE detects that one or both peers are behind a NAT device.

Recommendation:

This is normal, expected behavior for IPsec tunnels using NAT Traversal and does not indicate a problem. The counter will increment at the keepalive interval configured on the remote peer (typically every 20 seconds by default). If you see this counter incrementing but do not have any IPsec VPN tunnels configured with NAT-T, use packet capture on the outside interface to identify the source of the unexpected NAT-T traffic and determine whether it should be blocked with an access list. If IPsec tunnels are failing and this counter is not incrementing when expected, verify that UDP port 4500 is not blocked by intermediate firewalls or access lists, as NAT-T requires bidirectional UDP 4500 connectivity.

Syslogs:

None

----------------------------------------------------------------

no-adjacency

No valid adjacency

The device dropped the packet because it could not resolve the destination MAC address for the next-hop router or directly connected host. This occurs during Layer 2 adjacency resolution when forwarding a packet—the device has determined the egress interface and next-hop IP address through routing, but cannot obtain the corresponding MAC address needed to build the Ethernet frame. Common causes include missing or expired ARP entries (IPv4) or neighbor cache entries (IPv6), the next-hop host being unreachable or offline, routing table changes that invalidate cached adjacency information, or misconfigurations in features like zones, inter-VRF routing, Bridge Virtual Interfaces (BVI), or WCCP redirection. This drop is expected when the destination is genuinely unreachable, but may indicate a problem if it occurs for valid, reachable destinations.

Recommendation:

Use packet capture to identify the affected traffic and destination IP addresses. Verify that the next-hop IP address or destination host is reachable by checking the ARP table (show arp) or IPv6 neighbor table (show ipv6 neighbor) for the expected entry. If the entry is missing, confirm the host is online and connected to the correct network segment. Check the routing table (show route) to ensure the correct egress interface and next-hop are selected. If using zones with multiple interfaces, verify that all zone members have consistent routing and that ICMP inspection is not interfering with zone failover (see CSCvh47057). For BVI configurations, confirm member interfaces are up and MAC learning is functioning. If drops occur after idle periods on BVI setups, this may indicate a known issue (CSCwa19713). For VPN traffic with BGP, verify BGP routes are correctly installed and reachable. If the problem persists with valid, reachable destinations, collect packet-tracer output and contact Cisco TAC, as this may indicate a software defect in adjacency resolution for your specific configuration (zones, inter-VRF, WCCP, or transparent mode).

Syslogs:

None.

----------------------------------------------------------------

no-mcast-entry

Multicast forwarding entry removed

A multicast packet was sent to the control plane for processing, but the corresponding multicast forwarding entry no longer exists in the forwarding table. This occurs when multicast routing is disabled while active flows exist, when the forwarding table is cleared during configuration changes, or when multicast routing is re-enabled causing stale flow references. The device cannot forward the packet because it has no forwarding state for the multicast group.

Recommendation:

This counter typically increments during configuration changes and is usually transient. If multicast routing was intentionally disabled, no action is required—the counter reflects expected behavior. If multicast routing should be active, verify that 'multicast-routing' is enabled globally and that 'mfib forwarding' is enabled on the relevant interfaces. If the counter increments continuously during normal operation, check for configuration instability, interface flapping, or recent changes to virtual tunnel interfaces (VTI) or security zones. Use 'show mfib' to verify forwarding entries exist for the expected multicast groups. If the issue persists without configuration changes, collect 'show asp drop' with packet captures and contact Cisco TAC.

Syslogs:

None

----------------------------------------------------------------

no-mcast-intrf

Multicast packet has no valid output interfaces

The firewall attempted to forward a multicast packet but found no valid output interfaces in the multicast forwarding entry. This occurs when all receivers for the multicast group have left (normal behavior), or when the Output Interface List becomes temporarily empty during multicast routing state transitions. The counter also increments on High Availability standby units, which do not forward multicast traffic. In rare cases involving IGMP static-group configuration combined with PIM neighbor filtering, a timing condition can cause the interface list to become NULL when a multicast source pauses and then resumes transmission after the (S,G) route expires, resulting in packet loss until the UDP connection timeout expires and multicast state is rebuilt.

Recommendation:

Check whether multicast receivers still exist for the affected group using 'show igmp groups' and 'show mroute'. If receivers are present and traffic is expected, verify that PIM adjacencies are established on all required interfaces with 'show pim neighbor'. On High Availability pairs, confirm the active unit is forwarding multicast correctly; drops on the standby unit are expected and benign. If drops persist with active receivers, check for configuration combining 'igmp static-group' with 'pim neighbor-filter' on the same interface—this combination can trigger a known timing issue (CSCwe21187). As a workaround, reduce the UDP timeout for affected multicast flows to minimize recovery time. If the multicast source is known to pause transmission, ensure the pause duration is shorter than the multicast route timeout to prevent state expiration. Contact Cisco TAC if drops continue with stable sources and receivers.

Syslogs:

302015 (UDP connection built), 302016 (UDP connection teardown)

----------------------------------------------------------------

no-paired-ifc

Inline-set paired interface not found

This counter increments when a reverse-direction packet arrives on an inline-set interface, but the device cannot locate the corresponding paired interface to forward the packet. This occurs specifically when flow-sharing is enabled for inline-set interfaces. For example, if a connection is established between interfaces I1 and O1 in an inline-set, but the reverse flow arrives on O2 (which is part of the same inline-set), the system attempts to forward the packet out of the paired interface I2. If that paired interface cannot be found or is not properly configured, the packet is dropped. This situation typically indicates a configuration issue with the inline-set pairing, such as incomplete interface-pair definitions, tap-mode configuration problems, or interface state mismatches within the inline-set.

Recommendation:

Verify the inline-set configuration using 'show inline-set' to confirm that all interface pairs are properly defined and in the UP state. Check that both interfaces in each pair are operational and that the inline-set is not in a transitional state. If tap-mode is configured, ensure it was enabled before adding interface pairs to the inline-set, as changing the order can break pairing. Review recent configuration changes to inline-set definitions. If the counter increments during normal operation with a properly configured inline-set, capture dropped packets to identify which specific interface pair is affected. When flow-sharing is enabled across multiple interface pairs in the same inline-set, ensure all pairs are consistently configured. If the issue persists after verifying configuration, contact Cisco TAC with the output of 'show inline-set', 'show interface', and a packet capture of the dropped traffic.

Syslogs:

110004 (Egress interface changed)

----------------------------------------------------------------

no-route

No route to host

The device attempted to forward a packet but could not find a route to the destination address in the routing table. This occurs when the device performs a route lookup (in routed firewall mode) or bridge lookup (in transparent firewall mode) and no matching entry exists. Common scenarios include: missing static or dynamic routes to the destination network, NAT configuration requiring route lookup but no route available for the translated address, default route not configured when needed, routing protocol convergence issues where routes are temporarily unavailable, or VRF-aware routing where the destination is not reachable in the packet's VRF context. In clustered deployments with BGP, this can also occur due to a known issue where route entries become marked as 'unresolved' in the routing table despite being present, typically under high connection load with frequent route updates.

Recommendation:

Check the routing table using 'show route' to verify a route exists for the destination address shown in syslog 110001. If the route is missing, add a static route or configure the appropriate routing protocol. For NAT scenarios, ensure routes exist for post-translation addresses when 'perform route lookup' is enabled in the NAT policy. Verify the default route is configured if traffic is destined to networks outside your directly connected subnets. For VRF deployments, confirm the destination is reachable within the correct VRF using 'show route vrf <name>'. In clustered environments experiencing this issue with BGP, check 'show asp table routing address <destination>' — if the route shows as 'unresolved' with a matching timestamp, use 'show asp table routing address <destination> resolve' to force resolution, or consider upgrading to a fixed release (CSCwa03275). If drops persist after verifying routing configuration, collect 'show tech-support' and contact Cisco TAC.

Syslogs:

110001

----------------------------------------------------------------

no-route-to-peer-nve

No Route to Peer NVE

This counter increments when the device cannot determine the next-hop MAC address needed to reach a configured VXLAN or GENEVE peer Network Virtualization Edge (NVE) endpoint. This occurs during tunnel encapsulation when the device performs a routing table lookup for the peer VTEP IP address but fails to resolve the Layer 2 adjacency (next-hop MAC address) required to forward the encapsulated packet. The drop happens after the inner packet has been encapsulated with VXLAN or GENEVE headers but before it can be transmitted to the remote VTEP. Common scenarios include: a static peer IP configured without a corresponding route in the routing table, the peer IP unreachable via the configured source interface, ARP or neighbor discovery failure for the next-hop gateway, or the source interface being down or administratively disabled. This counter applies to both IPv4 and IPv6 VTEP configurations and affects both static peer and static peer group deployments.

Recommendation:

Verify that a valid route exists to the peer NVE IP address by checking the routing table with 'show route'. Confirm the peer NVE is reachable via the configured VTEP source interface using 'show nve 1' and 'show interface'. If using static peer configuration, ensure a static route or dynamic routing protocol provides reachability to the peer VTEP IP. Check ARP or IPv6 neighbor tables to confirm next-hop resolution for the gateway toward the peer. Verify the source interface is in an 'up' state and has IP connectivity to the underlay network. If the peer is on a directly connected subnet, confirm Layer 2 connectivity. For deployments using static peer groups, verify all peer IPs in the group are reachable. Review any recent routing changes, interface flaps, or configuration modifications that may have disrupted VTEP reachability. If the counter increments during initial configuration, this is expected behavior until routing is properly established—configure the necessary routes before adding the peer IP to avoid configuration errors.

Syslogs:

None

----------------------------------------------------------------

no-same-security-traffic

Hairpin traffic blocked (same-security-traffic not configured)

Traffic was dropped because it attempted to exit through the same physical interface it entered, but the configuration does not permit this hairpin (U-turn) behavior. This most commonly occurs in VPN hub deployments where traffic from one remote site must be decrypted, routed, and re-encrypted back out the same interface to reach another remote site (branch-to-branch communication through a central hub). It can also occur with service-chaining configurations where traffic loops back through the same interface after inspection. By default, the firewall blocks traffic that enters and exits the same interface, even if access lists would otherwise permit the flow.

Recommendation:

If hairpin traffic is expected and desired (such as branch-to-branch VPN traffic through a hub), configure 'same-security-traffic permit intra-interface' in global configuration mode. This is distinct from 'same-security-traffic permit inter-interface', which controls traffic between different interfaces that share the same security level. Verify that the traffic pattern genuinely requires hairpin routing—in VPN hub scenarios, this is normal and expected. Review routing and VPN configurations to confirm the traffic path is intentional. Note that some platforms or deployment modes may have limitations on intra-interface traffic support.

Syslogs:

None

----------------------------------------------------------------

no-v4-adjacency

No IPv4 adjacency for diagnostic packet

This counter increments when a diagnostic packet (packet-tracer simulation or capture with trace option) requires next-hop MAC address resolution but the adjacency is not already present in the device's table. Diagnostic packets are intentionally prevented from triggering ARP requests to avoid sending traffic onto the network during troubleshooting operations. The simulated or traced packet is dropped at this point. This is expected behavior when using packet-tracer or capture trace features to test connectivity to destinations that have not recently communicated with the device, or when the ARP entry has aged out. Normal production traffic would trigger ARP resolution and proceed once the MAC address is learned.

Recommendation:

This drop is normal for diagnostic operations and does not indicate a problem with production traffic. If you need packet-tracer to complete end-to-end testing including actual transmission, use the 'transmit' option which allows the simulated packet to egress and trigger ARP resolution. For production traffic troubleshooting, verify that the destination IP address is reachable and that ARP entries are being learned correctly using 'show arp' or 'show ipv6 neighbors'. If production traffic is also failing to reach the destination, check routing configuration, interface status, and whether the next-hop device is responding to ARP requests.

Syslogs:

None.

----------------------------------------------------------------

no-v6-adjacency

IPv6 Diagnostic Packet Dropped - No Adjacency

This counter increments when an IPv6 unicast packet injected by a diagnostic tool (packet-tracer or capture with trace option) cannot resolve the next-hop MAC address. Diagnostic tools intentionally do not trigger IPv6 Neighbor Discovery to avoid sending packets to the network during troubleshooting operations. When the device needs to forward an IPv6 packet but the destination MAC address is not already in the neighbor cache, normal traffic would trigger Neighbor Discovery (the IPv6 equivalent of ARP). However, simulated diagnostic packets are dropped instead to maintain the non-intrusive nature of these tools. This is expected behavior and does not indicate a problem with production traffic.

Recommendation:

This drop is normal and expected for packet-tracer and capture trace operations. It indicates that the IPv6 next-hop address is not currently in the neighbor cache. To verify that real traffic would succeed, check the IPv6 neighbor table with 'show ipv6 neighbor' to confirm the destination or next-hop address has a valid entry. If the neighbor entry is missing for production traffic, verify IPv6 connectivity and routing to the destination. For diagnostic purposes, ensure the target IPv6 address is reachable and has an active neighbor cache entry before running packet-tracer. This counter does not affect production traffic and requires no action unless you are troubleshooting why a specific IPv6 address lacks a neighbor entry.

Syslogs:

None.

----------------------------------------------------------------

no-valid-nve-ifc

No valid NVE interface

This counter increments when the device attempts to encapsulate outbound traffic through a VXLAN or GENEVE overlay interface but cannot locate the associated tunnel endpoint interface. This occurs when a VNI (VXLAN Network Identifier) or GENEVE interface is configured but has not been bound to an NVE (Network Virtualization Endpoint) instance using the vtep-nve command. The binding between the VNI interface and the NVE instance is mandatory for overlay encapsulation—without it, the device cannot determine which physical or logical interface should serve as the VXLAN/GENEVE tunnel source. This drop typically appears during initial configuration when the VNI interface exists but the vtep-nve association is missing or incomplete, or after configuration changes that remove the NVE binding. It can also occur in cluster environments when VNI interfaces are redirected across cluster control links without proper VTEP configuration synchronization.

Recommendation:

Verify that each VNI or GENEVE interface has been associated with an NVE instance. Under each VNI interface configuration, ensure the vtep-nve command is present and references a valid NVE instance (typically 'vtep-nve 1'). Check that the referenced NVE instance exists and is configured with a valid source interface using the 'nve 1' global configuration command. Use 'show nve' to confirm the NVE instance is operational and 'show interface vni' to verify the VNI-to-NVE binding. If the configuration appears correct but drops persist, verify that the NVE source interface is up and reachable. In cluster deployments, ensure VTEP and VNI configurations are consistent across all cluster members.

Syslogs:

None.

----------------------------------------------------------------

no-valid-vni-ifc

No VNI interface matches segment ID

The device received or processed a VXLAN packet but could not find a VNI interface configured with the required segment ID. This occurs in VXLAN overlay deployments with Service Tag Switching (STS) enabled, where the device translates between segment IDs to route traffic across VXLAN segments. After the STS lookup determines the egress segment ID for a packet, the device searches for a VNI interface configured with that segment ID. If no matching interface exists, the packet is dropped and this counter increments. Common causes include: a VNI interface was removed or shut down while still referenced in the STS mapping table; the segment ID configuration on a VNI interface was changed or removed; or the STS table contains mappings to segment IDs that were never configured on any VNI interface.

Recommendation:

Check syslog message 778002 to identify the specific segment ID that has no matching interface. Verify that a VNI interface is configured with that segment ID using 'show interface vni' and 'show running-config interface vni'. If the segment ID should be valid, add or correct the 'segment-id' command under the appropriate VNI interface configuration. If using STS tag-switching, verify the STS mapping table is consistent with your VNI interface segment ID assignments. If you recently changed a segment ID on a VNI interface, existing flows may reference the old segment ID until they time out; this is typically transient and self-correcting. If the segment ID in the syslog is unexpected, investigate the source of the VXLAN traffic to determine if it is misconfigured or malicious.

Syslogs:

778002

----------------------------------------------------------------

non-ip-pkt-in-routed-mode

Non-IP packet received in routed mode

The appliance received a Layer 2 frame that is not IPv4, IPv6, or ARP while operating in routed firewall mode. Routed mode is designed to process only Layer 3 IP traffic; non-IP protocols (such as IPX, AppleTalk, MPLS, or other Ethertypes) cannot be forwarded and are dropped. This counter also increments when non-IP traffic attempts to exit through a Bridge Virtual Interface (BVI) in routed mode with inter-VLAN routing enabled. In normal operation, the default Layer 2 access control configuration should prevent non-IP frames from reaching the forwarding path, so this counter typically indicates either a misconfiguration or a software defect. A known issue (CSCwc24178) caused ARP packets to be incorrectly dropped with this reason on port-channel sub-interfaces after configuration changes.

Recommendation:

If this counter increments, first verify that the appliance is configured in routed mode (not transparent mode) using 'show firewall'. Check whether the traffic involves Bridge Virtual Interfaces (BVIs) with 'show interface' and 'show running-config interface'. Review any Layer 2 access control lists to ensure non-IP protocols are explicitly denied before reaching the forwarding engine. If the drops involve ARP packets or occur after adding or modifying port-channel sub-interfaces, this may indicate a software defect; a chassis reload has resolved some instances. Persistent or unexplained drops should be reported to Cisco TAC with packet captures, interface configuration, and the output of 'show asp drop' to determine whether a software defect is present.

Syslogs:

106026, 106027

----------------------------------------------------------------

none

Snort Inspection Passed (Not Blocked)

This counter appears in the drop statistics but does not represent dropped packets. It increments when the Snort inspection engine examines a packet and returns a PASS verdict, meaning the packet was allowed to continue through the firewall. The counter is used internally for packet tracing and diagnostics to distinguish packets that were inspected and permitted from those that were blocked or dropped. On FTD platforms with threat defense enabled, this counter tracks packets that successfully passed Snort's intrusion prevention, file inspection, and application control checks without triggering any block or drop actions.

Recommendation:

This counter incrementing is normal and expected behavior — it indicates that Snort inspection is functioning and allowing legitimate traffic. A high value shows active inspection with traffic being permitted. No action is required. If you expect traffic to be blocked but see this counter incrementing instead, verify your intrusion policy rules, file policies, and access control policy settings in FMC to ensure blocking rules are properly configured and applied. Use packet-tracer or capture with trace enabled to see the specific Snort verdict for individual flows.

Syslogs:

None.

----------------------------------------------------------------

np-socket-closed

Dropped pending packets in a closed socket

Packets queued for transmission or reception through an internal socket were dropped because the socket closed before the packets could be processed. This occurs when SSL/TLS decryption, DTLS VPN tunnels, TCP proxy connections, or other socket-based services terminate while packets are still in the processing pipeline. The counter increments for each packet discarded during socket cleanup. Common scenarios include: SSL/TLS inspection sessions ending while crypto operations are in progress, VPN tunnels closing with queued encrypted or decrypted packets, TCP proxy connections terminating with buffered data, or abrupt connection resets that force immediate closure. This is normal during connection teardown and typically reflects the natural cleanup of in-flight packets when applications or protocols close connections.

Recommendation:

Low, steady increments are expected as part of normal operation when SSL/TLS inspection, VPN, or TCP proxy connections close. Investigate if the counter is rapidly increasing alongside connection failures, application timeouts, or service disruptions. Check for: SSL/TLS inspection policy misconfigurations causing premature session termination, VPN tunnel instability or frequent reconnections, TCP proxy resource exhaustion, or hardware crypto accelerator issues on platforms with offload capabilities. If the counter correlates with user-reported connectivity problems or service outages, collect troubleshooting bundles and contact Cisco TAC. Review 'show asp table socket' output to identify which socket types are affected and 'show conn' to check for abnormal connection patterns.

Syslogs:

None.

----------------------------------------------------------------

np-socket-lock-failure

Packets dropped when unable to acquire connection lock during hardware-accelerated crypto processing

This counter increments when packets are dropped because the device cannot acquire an internal connection lock needed to process the results of hardware-accelerated cryptographic operations. This occurs specifically during SSL/TLS or DTLS encryption and decryption for SSL VPN (AnyConnect Remote Access VPN) connections, SSL decryption policies, or other SSL/TLS-based features that use hardware crypto acceleration. When a crypto operation completes asynchronously on the hardware accelerator, the callback handler must acquire a per-connection lock to safely process the encrypted or decrypted data. If that lock is already held by another thread or operation, the packet cannot be processed and is dropped. This typically indicates lock contention during high connection load, concurrent operations on the same connection, or transient delays in crypto hardware processing. The counter may also increment during connection teardown if crypto callbacks complete after the connection has begun closing.

Recommendation:

Small, occasional increments are generally benign and may occur during normal connection teardown or brief periods of high load. Sustained or rapidly increasing counters indicate a performance or resource issue. Check for high CPU utilization on data plane cores, excessive numbers of concurrent SSL VPN sessions, or hardware crypto accelerator saturation. Review 'show crypto accelerator statistics' and 'show vpn-sessiondb' output to assess crypto load and active session counts. If the device is terminating a large number of Remote Access VPN sessions with RSA-based server certificates, consider using ECDSA certificates with ECDHE cipher suites where client compatibility allows, as this reduces lock contention in the crypto path. On platforms with configurable crypto acceleration (such as Firepower 4100/9300 series), verify that the crypto accelerator bias is appropriately configured for your workload mix (SSL vs. IPsec). If drops persist under normal load, contact Cisco TAC with output from 'show asp drop', 'show crypto accelerator statistics', 'show vpn-sessiondb', and 'show processes cpu-usage non-zero' to investigate potential software issues or hardware crypto problems.

Syslogs:

None.

----------------------------------------------------------------

np-sp-invalid-spi

Invalid SPI

The device received an IPsec packet with a Security Parameter Index that does not match any currently active security association. This occurs when the packet references an SPI that the device has not yet installed, has already deleted, or never knew about. The most common cause is a timing race during IPsec rekey operations, particularly with peer devices that immediately begin using new outbound SPIs before the receiving device has finished installing the corresponding inbound SA. This can also occur with fragmented IPsec packets, stale packets arriving after an SA has been torn down, or packets sent to the wrong device. In rare cases, sustained high rates may indicate a denial-of-service attack using spoofed or replayed IPsec packets.

Recommendation:

Occasional invalid SPI drops are normal and expected, especially during rekey operations or when tunnels are being torn down. If you observe frequent drops that correlate with tunnel instability or application disruptions during rekey, check whether the peer device is configured with shorter SA lifetimes than the local device—configure the local device with a shorter lifetime so it becomes the rekey responder rather than initiator. If drops occur continuously at high rates without active tunnels, investigate whether the device is receiving IPsec traffic intended for a different endpoint or is under attack; use packet captures to identify the source and SPI values. For cluster deployments, verify that VPN ownership is stable and that all members have consistent tunnel state. If drops affect non-VPN protocols (such as routing protocol packets), verify that traffic classification and crypto map configuration are correct. Contact Cisco TAC if invalid SPI drops cause persistent tunnel flapping or if you observe the issue with specific peer vendors after software upgrades.

Syslogs:

402114

----------------------------------------------------------------

object-group-search-threshold-exceeded

Object group search threshold exceeded

This counter increments when a packet is dropped because access list evaluation exceeded the configured complexity limit of 10,000 object group matches. This occurs only when both the 'object-group-search access-control' optimization and 'object-group-search threshold' enforcement are enabled. The object-group-search feature reduces memory consumption by avoiding full ACL expansion, but requires the device to search through network object groups at runtime for each packet. When a packet's source and destination addresses match an excessive number of overlapping network objects across multiple object groups, the cumulative search count can exceed the 10,000-match safety threshold. This typically happens with poorly structured object groups containing many overlapping IP ranges, duplicate entries, or overly broad network definitions that cause a single packet to match hundreds of source objects and hundreds of destination objects.

Recommendation:

First, identify the dropped traffic using 'capture asp-drop type asp-drop object-group-search-threshold-exceeded'. Review the associated syslog messages (815002 or 815003) which identify the specific source and destination addresses triggering the threshold. Examine your network object groups for overlapping IP ranges, duplicate entries, or overly broad definitions—for example, multiple object groups each containing 10.0.0.0/8 alongside more specific subnets. Consolidate or restructure object groups to eliminate redundancy and reduce overlap. If the threshold is being hit legitimately due to complex but necessary policy requirements, you can disable the threshold enforcement with 'no object-group-search threshold' (packets will still be processed but you'll receive warning syslogs when the 10,000 limit is exceeded), or disable the entire optimization with 'no object-group-search access-control' to return to full ACL expansion (which consumes more memory but eliminates per-packet search overhead). Monitor CPU utilization and memory usage when making changes, as the object-group-search feature represents a memory-versus-CPU trade-off.

Syslogs:

815002, 815003

----------------------------------------------------------------

packet-infinite-looping

Packet loopback infinite loop detected

This counter increments when the firewall detects that a packet attempting to re-enter the data path would create an infinite loop. The firewall uses packet loopback (re-injection) for legitimate processing scenarios such as IPsec decryption, policy-based routing, and NAT transformations, where a packet must be reprocessed after first-leg operations. The infinite loop condition is detected when the packet's ingress and egress interfaces are identical, or when the egress interface is null, indicating the packet would be sent back to the same interface it came from indefinitely. This is a protective drop that prevents the packet from consuming system resources in an endless processing cycle.

Recommendation:

This drop typically indicates a configuration issue or software defect rather than normal traffic behavior. Common scenarios include: (1) VTI tunnels using a loopback interface as the tunnel source combined with NAT-T (NAT Traversal) enabled—this was a known issue fixed in ASA 9.18.3.39+ and 9.19.1+ (see CSCwc67031); workaround is to use a physical interface as the tunnel source instead of loopback. (2) Routing misconfigurations where the next-hop lookup for a packet points back to the same interface. (3) Incorrect policy-based routing rules that create routing loops. Check the console or system logs for 'ERROR: infinite looping of packet on interface <name>' messages that identify the affected interface. Review VTI tunnel source configurations, routing tables, and policy-based routing rules for the identified interface. If the issue persists after configuration review and you are running an affected software version, upgrade to a fixed release. If the problem occurs on current software without VTI/loopback configurations, contact Cisco TAC with the interface name and traffic details.

Syslogs:

None

----------------------------------------------------------------

passenger-flow-handling-failed

Tunnel passenger flow processing error

This counter increments when the device encounters an internal processing error while handling decapsulated tunnel traffic. The device supports inspection of inner (passenger) flows within GRE and IP-in-IP tunnels by decapsulating the outer tunnel header, inspecting the inner traffic, and then re-encapsulating it before forwarding. This counter tracks failures during that process, including: inability to acquire internal processing locks needed to re-inject the decapsulated packet into the inspection pipeline, unavailability of the outer tunnel flow context when attempting to re-encapsulate the packet for egress, failure to obtain an internal work queue for dispatching the re-encapsulated packet, or failure to determine the correct re-injection point in the processing pipeline. These errors typically occur under high load, in cluster deployments with fragmented tunnel traffic, or when packet ordering causes the device to process the inner flow before the outer tunnel flow is fully established.

Recommendation:

This drop usually indicates a transient resource contention issue during tunnel traffic processing. If the counter increments occasionally, no action is required—the affected connections will typically recover through retransmission. If the counter increments frequently and impacts tunnel traffic: (1) Check for high CPU utilization or memory pressure on the device. (2) If running in a cluster, verify cluster health and check for fragmentation issues over the tunnel (see related counter 'passenger-flow-failed'). (3) Consider using a Prefilter Policy with a Tunnel rule matching the affected GRE or IP-in-IP traffic and setting the action to 'Fastpath' to bypass deep inspection of the inner flows—this trades inspection depth for reliability. (4) Review tunnel MTU settings to minimize fragmentation. (5) If the issue persists and significantly impacts traffic, contact Cisco TAC with 'show asp drop' output, 'show conn' filtered for the tunnel endpoints, and a packet capture showing the dropped traffic.

Syslogs:

None

----------------------------------------------------------------

passenger-flow-invalid-encap-request

Invalid outer IP version for GRE tunnel encapsulation

The appliance dropped a packet while attempting to add a GRE tunnel header because the requested outer (carrier) IP version was invalid. GRE tunnels require either IPv4 or IPv6 as the outer IP protocol. This counter increments when the tunnel flow metadata specifies an outer IP version that is neither IPv4 nor IPv6, indicating either internal state corruption or a misconfigured tunnel. This occurs during re-encapsulation of decapsulated tunnel traffic (passenger flows) when the appliance attempts to restore the original GRE tunnel header before forwarding the packet.

Recommendation:

This drop typically indicates an internal software error or corrupted flow state. Verify the GRE tunnel configuration specifies a valid outer IP version (IPv4 or IPv6). If the tunnel configuration is correct, collect the output of 'show asp drop', 'show conn detail', and 'show asp table classify' along with packet captures on both tunnel interfaces. Contact Cisco TAC if the drops persist, as this may indicate a software defect requiring further investigation.

Syslogs:

None

----------------------------------------------------------------

passenger-flow-malformed-packet

Tunnel re-encapsulation failed due to malformed or oversized header

This counter increments when the firewall cannot re-encapsulate a tunneled packet after inspecting its inner content. The firewall decapsulates supported tunnel protocols (such as GRE, IPsec VPN, or IP-in-IP) to inspect the inner traffic flows, then must restore the original tunnel headers before forwarding. This drop occurs when the cached tunnel header information is malformed, incomplete, or exceeds the maximum supported buffer size for re-encapsulation. Common scenarios include fragmented packets traversing tunnels (especially when fragments arrive out of order), tunnel traffic in cluster deployments where the original outer tunnel flow information is unavailable on the processing node, or tunnels with unusually complex or nested encapsulation that results in oversized headers.

Recommendation:

Check whether the drops correlate with fragmented traffic over tunnels using packet captures on both tunnel endpoints. If running a cluster, verify that tunnel flows are properly distributed and that cluster health is normal, as this can occur when the node processing the inner flow lacks access to the outer tunnel flow state. For GRE or IPsec tunnels carrying fragmented traffic, consider whether the tunnel MTU can be increased or whether Path MTU Discovery is functioning correctly to reduce fragmentation. If drops are persistent and impacting traffic, collect the output of 'show asp drop', 'show conn detail' filtered for tunnel traffic, and 'show flow-offload' (if applicable), then contact Cisco TAC. In some cases, temporarily bypassing deep inspection for specific tunnel traffic using prefilter rules may serve as a workaround while investigating the root cause.

Syslogs:

None

----------------------------------------------------------------

passenger-flow-no-encap-info

Tunnel re-encapsulation failed due to missing outer tunnel information

This counter increments when the device attempts to send a self-generated packet (such as a TCP reset or ICMP error message) back through a tunnel but cannot re-encapsulate it because the outer tunnel header information is unavailable. This occurs with decapsulated tunnel traffic (GRE or IP-in-IP) when the device needs to generate a response packet but has no record of the original outer tunnel flow. The inner (passenger) flow exists, but the system cannot reconstruct the outer (carrier) tunnel header needed to send the packet back through the tunnel. Common scenarios include TCP resets sent in response to denied connections through tunnels, ICMP error messages generated for tunneled traffic, or fragmented packets in cluster environments where tunnel state is incomplete.

Recommendation:

This drop typically indicates a transient condition where tunnel state information was not fully established or was lost. Check for: (1) Tunnel flapping or instability—verify GRE or IP-in-IP tunnel status and routing; (2) Cluster synchronization issues—in multi-node deployments, ensure cluster members are properly synchronized and tunnel state is being replicated; (3) High connection rates through tunnels that may cause state table exhaustion; (4) Fragmented traffic over tunnels in cluster configurations (known issue fixed in 9.12.3 and later via CSCvo50353). If the counter increments persistently, capture packet traces on both tunnel endpoints to identify which traffic patterns trigger the condition. For cluster deployments experiencing this with fragmented tunnel traffic, upgrade to 9.12.3 or later. If the counter increments occasionally during tunnel reconvergence or failover events, it is typically benign.

Syslogs:

None

----------------------------------------------------------------

passenger-flow-unsupported-encap

Tunnel re-encapsulation failed due to unsupported encapsulation type

This counter increments when the device attempts to re-encapsulate tunneled traffic but cannot extract the original tunnel header information because the encapsulation type is not supported. This occurs during passenger flow processing when the device needs to restore the outer tunnel header on decapsulated traffic (for example, when sending TCP resets or handling self-sourced packets through tunnels). The device supports GRE, IP-in-IP (protocol 4), and IPv6-in-IP (protocol 41) tunnels. The drop happens when the outer tunnel uses an unsupported Layer 3 protocol, an unrecognized ethertype, or when Layer 2 or Layer 3 header decoding fails on the original tunneled packet. This is most commonly seen with GRE tunnels in multi-node cluster environments, particularly when handling fragmented traffic or when the carrier flow context is unavailable.

Recommendation:

Verify that your tunnel configuration uses a supported encapsulation type (GRE, IP-in-IP, or IPv6-in-IP). Check for malformed tunnel headers or unusual Layer 2 encapsulation on the ingress interface. If you are running a multi-node cluster with GRE tunnels and see this drop with fragmented traffic, this may indicate a known issue (CSCvo50353) fixed in version 9.12.3 and later. For GRE tunnels experiencing passenger flow drops, consider creating a Prefilter policy Tunnel rule matching the affected GRE traffic with the action set to Fastpath, then clear the affected connections. If drops persist with supported tunnel types, collect packet captures on both sides of the tunnel and contact Cisco TAC with the output of 'show asp drop' and 'debug passenger' to identify which specific encapsulation characteristic is triggering the failure.

Syslogs:

None

----------------------------------------------------------------

passenger-flow-unsupported-payload

Tunnel inner traffic with unsupported protocol

This counter increments when the firewall decapsulates tunnel traffic (GRE or IP-in-IP) to inspect the inner payload, but cannot re-encapsulate the traffic for egress because the inner protocol is not supported. The firewall's tunnel inspection feature (passenger flow processing) currently supports only TCP as the inner protocol for outbound traffic that originates from behind the firewall. When the firewall receives tunneled traffic containing inner protocols such as UDP, ICMP, or other IP protocols, and that traffic needs to be re-encapsulated after inspection, the packet is dropped. This typically occurs when the firewall is positioned between tunnel endpoints and is configured to inspect the decapsulated inner flows, but the inner traffic uses a protocol other than TCP.

Recommendation:

This drop indicates a protocol support limitation in the tunnel inspection feature. If you are seeing these drops, verify the inner protocol of your tunneled traffic. If the inner traffic is UDP, ICMP, or another non-TCP protocol, consider one of these options: (1) Configure a Prefilter policy with a Fastpath rule matching the tunnel traffic to bypass deep inspection and allow the tunnel to pass through without decapsulation, or (2) Adjust your network design so the firewall does not need to decapsulate and re-encapsulate this traffic. If the drops are affecting critical applications, contact Cisco TAC to discuss your specific topology and requirements. Note that this is a current design limitation of the passenger flow feature, which was introduced in FTD 6.3.0.

Syslogs:

None

----------------------------------------------------------------

pat-pool-interface-mismatch

PAT Pool Interface Mismatch

The firewall rejected a new connection attempt because the dynamic PAT rule's interface configuration has changed while active translations still exist from the previous configuration. This occurs when you modify a dynamic PAT rule to change the egress interface specification—for example, changing from a specific interface to 'any' interface, or vice versa—without first clearing the existing translations that were created under the old rule. The internal port allocation tracking structures retain the original interface binding, and when a new connection arrives, the system detects the inconsistency between the current rule's interface and the interface associated with the active port allocations. The firewall drops the new connection to prevent mismatched state between the configuration and runtime data.

Recommendation:

This drop indicates a configuration change workflow issue. To resolve: (1) Remove or modify the NAT rule that caused the mismatch. (2) Clear all active translations associated with the affected PAT pool using 'clear xlate global <ip-range>' on all cluster nodes if applicable. (3) Verify no translations remain using 'show xlate global <ip-range>' or 'cluster exec show xlate global <ip-range>' in a cluster. (4) Reapply the NAT rule with the desired interface configuration. To avoid this issue during configuration changes, always clear relevant translations before modifying dynamic PAT rules that change interface specifications. This counter is most commonly seen with CGNAT configurations using block-allocation, but can occur with any dynamic PAT rule that changes between specific and 'any' interface specifications.

Syslogs:

None.

----------------------------------------------------------------

pat-port-block-state-mismatch

PAT Port Block State Mismatch

The device detected a configuration mismatch between the current dynamic PAT rule and existing port allocation state in a cluster deployment. This occurs when a dynamic PAT rule is modified to add or remove the 'block-allocation' keyword while active translations from the previous configuration still exist. Port block allocation is a carrier-grade NAT feature that pre-allocates contiguous blocks of ports to each internal host for improved scalability in cluster environments. When the allocation mode changes (regular PAT to block-allocation or vice versa), the system cannot safely allocate new ports until the old state is cleared, because cluster members would have inconsistent views of port ownership. New connection attempts are dropped until the mismatch is resolved. This counter only increments in cluster deployments; standalone and high-availability pairs are not affected.

Recommendation:

This drop is expected after changing PAT pool configuration between regular and block-allocation modes. To resolve: (1) Remove the NAT policy that was modified, (2) Clear all active translations using the affected global IP addresses with 'cluster exec clear xlate global <ip-address>' or 'cluster exec clear xlate global <start-ip>-<end-ip>' for a range, (3) Verify no translations remain with 'cluster exec show xlate global <ip-address>', (4) Re-apply the NAT policy with the desired configuration. If drops persist after clearing translations, verify that all cluster members have consistent NAT configuration and that the cluster control link is operational. If you did not recently modify PAT configuration and see this counter incrementing, contact Cisco TAC as it may indicate a cluster synchronization issue.

Syslogs:

None directly associated. Related cluster PAT messages include 305022 (unequal port block allocation) and 305014 (port block allocation events).

----------------------------------------------------------------

pbr-next-hop-same

Policy-based routing next-hop resolves to the device itself

This counter increments when a policy-based routing (PBR) rule matches traffic and the configured next-hop address resolves to an IP address assigned to the device itself, rather than to an external gateway. When PBR performs a route lookup for the configured next-hop, if that address belongs to one of the device's own interfaces, forwarding the packet would create a routing loop. The device drops the packet to prevent this condition. This typically occurs when the route-map uses 'set ip next-hop' or 'set ipv6 next-hop' with an IP address that is configured on one of the device's interfaces, or when the next-hop resolves through the routing table to a locally-connected address on the device.

Recommendation:

Review the policy-based routing configuration on the ingress interface where drops are occurring. Use 'show route-map' to identify which route-maps are applied and examine the 'set ip next-hop' or 'set ipv6 next-hop' statements. Verify that the configured next-hop addresses point to external routers or gateways, not to IP addresses assigned to the device's own interfaces. If the next-hop must be on a directly connected subnet, ensure it specifies a neighbor device's IP address, not the device's interface address. If you need to redirect traffic to a different interface on the same device, use 'set interface' instead of 'set ip next-hop'. Check the routing table with 'show route' to confirm the next-hop addresses resolve to external destinations. This drop is a protective measure and indicates a configuration error that would otherwise cause a routing loop.

Syslogs:

None

----------------------------------------------------------------

pdts-non-fragmented-pkt-received-err

Non-fragmented packet received during fragment reassembly

This counter increments when the firewall receives a complete (non-fragmented) packet back from the Snort inspection engine while it is actively reassembling a different set of fragmented packets for the same connection. When large packets are sent to Snort for deep packet inspection, the data plane may fragment them to fit within internal transport limits. Each fragment is tracked with a unique identifier and sequence number. The firewall expects to receive all fragments of a set before processing the next packet. This drop occurs when a non-fragmented packet arrives unexpectedly while fragments from a previous packet are still pending reassembly, indicating a state mismatch in the inspection pipeline. This typically points to an internal communication issue between the data plane and Snort inspection processes, such as out-of-order packet returns, dropped fragments, or Snort processing anomalies that disrupt the expected fragment sequence.

Recommendation:

This counter indicates an internal inconsistency in the Snort inspection pipeline and should not occur during normal operation. If this counter increments, enable 'debug packet-module pdts' to capture detailed communication between the data plane and Snort processes. Review the output for fragment ID mismatches, out-of-order returns, or Snort instance errors. Check 'show asp inspect-dp snort counters' for other anomalies such as queue overflows or Snort instance failures that might disrupt packet ordering. Verify that Snort processes are healthy using 'show snort statistics' and check for Snort restarts or crashes in system logs. If the issue persists or occurs frequently, collect a troubleshooting bundle and contact Cisco TAC, as this may indicate a software defect in the PDTS reassembly logic or Snort packet handling.

Syslogs:

None

----------------------------------------------------------------

pdts-punt-limit-exceeded

Inspection queue to Snort exceeded limit

This counter increments when packets destined for Snort inspection cannot be queued because the shared-memory ring buffer between the datapath and a Snort inspection instance has reached its high-water threshold. This occurs on FTD platforms when traffic requiring deep packet inspection (intrusion prevention, file inspection, application visibility) arrives faster than Snort can process it. The queue typically fills when Snort instances are CPU-saturated, processing complex signatures against high-bandwidth flows, or experiencing performance degradation. Each datapath thread maintains separate queues to each Snort instance; saturation can be per-instance or system-wide depending on load distribution.

Recommendation:

Check Snort instance health with 'show asp inspect-dp snort counters summary queues' to identify which instances have high queue depth or drops. Use 'show asp inspect-dp snort queue-exhaustion' to view automatic packet captures taken during saturation events. Review 'show snort statistics' for CPU utilization and rule evaluation performance. If drops are sustained, consider: reducing inspection scope by tuning intrusion policies to disable unused rule categories, adjusting file inspection depth limits, or upgrading to a higher-capacity platform. Transient drops during traffic bursts are normal; persistent drops indicate Snort capacity is insufficient for the traffic profile. If accompanied by syslog 850002 (Automatic Application Bypass), Snort has become unresponsive and traffic is bypassing inspection—collect a troubleshooting bundle and contact TAC.

Syslogs:

850002

----------------------------------------------------------------

pdts-received-first-pkt-fragment-id-ooo

Snort inspection fragment reassembly failed due to out-of-order first fragment

This counter increments when the device drops a fragmented packet returning from the Snort inspection engine because fragments arrived out of sequence. On FTD platforms, fragmented packets sent to Snort for deep packet inspection must be reassembled in the data plane after inspection completes. The system expects to receive fragment number 1 first to begin reassembly, but instead received a later fragment (fragment 2, 3, or higher). This indicates a sequencing problem in the communication channel between the data plane and the Snort inspection process. The affected flow is marked as having a reassembly error, and subsequent fragments from the same packet are also dropped until a new fragmentation sequence begins.

Recommendation:

This counter typically indicates an internal communication issue between the data plane and Snort inspection engine, not a network-level problem. Enable 'debug packet-module pdts' to trace the communication between the data plane and Snort processes. Review 'show asp inspect-dp snort counters' to check for PDTS queue health issues, backpressure, or dropped messages that could cause fragments to arrive out of order. If the counter increments frequently, collect a troubleshooting bundle and contact Cisco TAC, as this may indicate resource exhaustion, timing issues during high load, or a software defect affecting the inspection pipeline. Check for any Snort process restarts or automatic application bypass events that could disrupt fragment sequencing.

Syslogs:

None.

----------------------------------------------------------------

pdts-received-pkt-fragment-id-ooo

Fragment ID mismatch during Snort inspection reassembly

This counter increments when the threat defense engine receives fragmented packets back from the Snort inspection engine with an unexpected fragment identifier. When fragmented IP packets are sent to Snort for deep packet inspection, the datapath tracks the fragment ID and sequence for each flow to properly reassemble the inspected fragments. If Snort returns a fragment with a different fragment ID than expected for that flow's reassembly sequence, the packet is dropped and this counter increments. This typically indicates fragments from different packets are being interleaved during inspection, or fragments are arriving out of the expected order after inspection processing. This counter is specific to FTD platforms with Snort inspection enabled.

Recommendation:

This drop usually indicates a transient condition during high-volume fragmented traffic inspection. Check 'show asp inspect-dp snort counters' to verify Snort instance health and queue status. Review 'show fragment' output to identify if fragment reassembly issues exist at the IP layer before Snort inspection. If drops are persistent and impacting traffic, enable 'debug pdts 7' to capture detailed reassembly state information, then collect a troubleshooting bundle and contact Cisco TAC. Verify that fragment timeout settings are appropriate for your network conditions using 'show running-config fragment'. In most cases, occasional drops of this type are benign and represent normal handling of out-of-sequence fragments during inspection.

Syslogs:

None.

----------------------------------------------------------------

pdts-received-pkt-fragment-num-ooo

Fragment returned from Snort inspection with unexpected sequence number

This counter increments when the threat defense engine receives IP fragments back from the Snort inspection engine in an unexpected order during reassembly. When fragmented packets are sent to Snort for deep packet inspection on IPS-enabled interfaces, each fragment is tracked with a sequence number. After inspection, fragments must return in the correct sequence to be reassembled. If a fragment arrives with a sequence number that does not match the next expected value, the system cannot safely reassemble the packet and drops it. This typically occurs on FTD platforms with intrusion prevention policies applied to traffic, particularly when processing fragmented IP packets through inline inspection. The condition may indicate timing issues in the Snort inspection pipeline, resource contention affecting fragment processing order, or rare race conditions during high-throughput fragmented traffic inspection.

Recommendation:

This counter usually indicates an internal processing anomaly rather than a configuration issue. If the counter increments occasionally with no user impact, no action is required—the system is protecting against potentially malformed reassembly. If the counter increments frequently or correlates with dropped connections, collect diagnostic data: enable 'debug pdts 7' to see detailed fragment tracking, review 'show snort statistics' for inspection queue depth and processing delays, and check 'show asp drop' for related counters (pdts-received-first-pkt-fragment-id-ooo, pdts-received-pkt-fragment-id-ooo). Verify that fragmented traffic patterns are legitimate and not the result of an attack or misconfigured upstream device. If the issue persists and affects production traffic, collect a troubleshooting bundle and contact Cisco TAC, as this may indicate resource exhaustion or a software defect in the Snort inspection pipeline.

Syslogs:

None.

----------------------------------------------------------------

pdts-received-pkt-marked-drop-by-dp

Fragment dropped during flow teardown

This counter increments when a fragmented packet arrives for reassembly after the associated connection has been marked for deletion due to timeout or other cleanup processing. When the inspection engine returns a fragment to the datapath for reassembly, the datapath checks whether the flow is still active. If the flow has entered teardown (typically due to idle timeout, absolute timeout, or administrative removal), any pending fragments are dropped because reassembly cannot proceed on a flow being freed. This is a normal cleanup behavior that prevents resource leaks when flows time out while fragments are still in transit through the inspection pipeline.

Recommendation:

This counter typically increments during normal operation when flows time out while fragmented packets are being inspected. Occasional increments are expected and benign, especially in environments with long inspection latencies or aggressive flow timeout settings. If this counter increments frequently, verify that flow timeout values are appropriate for your traffic patterns—very short timeouts may cause flows to expire before inspection completes. Review connection timeout settings and consider whether inspection processing delays are causing flows to time out prematurely. If the counter grows rapidly alongside other fragment-related drops, investigate whether fragment floods or inspection performance issues are present. Use debug commands to correlate drops with specific flows if troubleshooting is needed.

Syslogs:

None.

----------------------------------------------------------------

pdts-snort-info-missing

Threat inspection metadata missing

This counter increments when a connection that requires deep packet inspection is missing the internal metadata needed to communicate with the threat detection engine. The packet is dropped and the flow is torn down. This typically occurs when the system cannot allocate or initialize the communication structures needed to send traffic for inspection during connection setup. The condition is most commonly seen during memory pressure, on virtual platforms (FTDv, ASAv), or when the inter-process communication queues between the firewall data plane and threat engine become stuck or corrupted. ICMP error packets are exempted from this drop and are bypassed instead.

Recommendation:

Check system memory utilization with 'show memory' and 'show blocks'. On FTD, verify threat detection engine health with 'show asp inspect-dp snort counters' and look for stuck PDTS queues (TX utilization at 100%). Review 'show asp drop' for related counters such as 'snort-busy' or 'failed-to-setup-pdts-flow-param' which may indicate broader communication issues between the data plane and inspection engine. If drops persist on virtual platforms, verify that sufficient memory is allocated to the VM and consider upgrading to a release with improved buffer management. For NAT64 configurations on virtual platforms, a prefilter fastpath rule for affected traffic may work around the issue. If drops continue or system memory appears healthy, contact Cisco TAC with the output of 'show tech-support' and packet captures showing the dropped flows.

Syslogs:

None

----------------------------------------------------------------

permit-validate

Permit validation failed

The firewall dropped a packet during initial connection setup because a custom validation check failed. This mechanism is used by features that need to verify additional criteria beyond standard access control rules before allowing a connection to proceed. The most common scenario is AnyConnect VPN DTLS session establishment, where the firewall validates that incoming DTLS ClientHello packets contain a session identifier that matches an existing VPN session. The validation ensures that DTLS handshake attempts are associated with an active SSL VPN session before allocating resources. Validation failures typically occur when a client attempts to establish a DTLS tunnel without first completing the SSL VPN authentication phase, when session state has been lost on the firewall, or when malformed or replayed DTLS packets arrive.

Recommendation:

If this counter is incrementing, identify which feature is performing validation by correlating with other symptoms. For AnyConnect VPN deployments, check whether DTLS sessions are failing to establish while SSL sessions succeed—this indicates the DTLS validation is rejecting packets. Review VPN session logs and AnyConnect client diagnostics to determine if clients are attempting DTLS connections before SSL authentication completes, or if session state is being prematurely cleared on the firewall. Verify that DTLS is properly enabled in the group policy configuration. If the counter increments rapidly from a specific source, investigate whether the host is sending malformed DTLS packets or attempting session replay attacks. For non-VPN scenarios, consult TAC to identify which feature registered the validation rule and why packets are failing the check. Occasional increments during normal VPN operation may be benign, especially during session transitions or client reconnects.

Syslogs:

None.

----------------------------------------------------------------

pkt-inject-queue-limit

Packet injection queue limit reached

The device drops packets when they cannot be queued for re-injection into the datapath because the target processing queue has reached its limit of 1000 packets. Packet re-injection occurs when traffic must be processed a second time after certain operations, including decryption of IPsec VPN traffic, DNS inspection with Cisco Umbrella, high-availability state synchronization, Zero Trust Network Access (ZTNA) proxy operations, and TCP proxy processing. The device maintains 32,768 separate queues (selected by flow hash) to distribute load across multiple processor cores. When a specific queue fills to capacity, additional packets destined for that queue are dropped to prevent memory exhaustion. This counter typically increments during sustained high traffic loads, particularly when VPN decryption, deep packet inspection, or proxy features create a backlog of packets awaiting re-processing. The drops are localized to flows hashing to the congested queue and do not affect other traffic.

Recommendation:

Moderate increments during traffic spikes are normal and indicate the backpressure mechanism is protecting system stability. Investigate if this counter grows continuously or reaches high values. Check for block memory depletion using 'show blocks' and look for exhaustion of 1550-byte or 9344-byte blocks. Identify which features are active (IPsec VPN, Umbrella DNS inspection, ZTNA, TCP proxy) and whether traffic patterns create processing bottlenecks. For VPN-heavy environments, verify that hardware crypto acceleration is enabled and functioning. If drops persist under normal load, consider whether inspection policies are appropriate for the traffic volume, or whether the platform is undersized for the workload. High sustained values may indicate a need to reduce inspection depth, adjust traffic policies, or upgrade to a higher-capacity platform. Contact Cisco TAC if drops occur without corresponding high CPU utilization or memory pressure, as this may indicate a software issue.

Syslogs:

None

----------------------------------------------------------------

platform-unlicensed

Virtual platform is unlicensed

The virtual appliance (ASAv or FTDv) is operating without a valid license and is blocking all data traffic that traverses the device. This counter increments when new connection attempts are denied during flow creation because the licensing subsystem has determined the platform is unlicensed. Traffic destined to or from the appliance itself (management traffic) is not affected—only through-the-box data plane traffic is blocked. This condition typically occurs when: (1) an ASAv has never been licensed after initial deployment, (2) a time-based evaluation license has expired and no permanent license was applied, (3) Smart Licensing registration has failed or expired beyond the grace period, or (4) the licensing subsystem failed to install rate-limiting enforcement and fell back to blocking all traffic as a fail-safe. The block is enforced at flow creation time in the data path before any security policy evaluation occurs.

Recommendation:

Check the current license state with 'show activation-key' (for traditional licensing) or 'show license all' (for Smart Licensing). For ASAv with traditional licensing, verify that a valid activation key is installed and has not expired. For Smart Licensing deployments, verify the device is registered with the Smart Licensing server, the evaluation period has not expired, and entitlements are in compliance. If the device shows 'Unlicensed' or 'Evaluation Expired', install the appropriate platform license or re-register with Smart Licensing. If the license appears valid but traffic is still blocked, check for syslog messages in the 444xxx range indicating licensing errors, particularly messages about rate limiter installation failures. In rare cases where rate-limiting enforcement cannot be configured, the system blocks all traffic as a protective measure—this requires investigating why the QoS rate limiter subsystem failed. This drop is by design and will persist until valid licensing is applied; there is no workaround other than proper licensing.

Syslogs:

444004, 444008, 444009 (license expiration); licensing subsystem error messages if rate limiter installation fails

----------------------------------------------------------------

pmtu-reinject-fail

ICMP Path MTU Error Message Dropped Due to Queue Full

The device attempted to send an ICMP error message back to a sender to notify them that their packet was too large for the outbound interface MTU (ICMP 'Fragmentation Needed' for IPv4 or 'Packet Too Big' for IPv6), but the internal work queue used to process these error messages was full. The ICMP notification was dropped, meaning the sender will not be informed of the MTU limitation. This counter only increments on multicore platforms (Firepower 2100, 4100, 9300 series and similar) where ICMP error generation is handled asynchronously through a dispatch queue. The original oversized data packet that triggered the MTU issue was already dropped; this counter specifically tracks the failure to send the ICMP notification about that drop.

Recommendation:

This counter typically indicates the device is under heavy load or experiencing processing delays that are filling the internal work queues. Investigate overall system health: check CPU utilization, memory usage, and other ASP drop counters (particularly 'dispatch-queue-limit'). If this counter is incrementing frequently, hosts on your network may be unable to perform proper Path MTU Discovery, leading to connection failures or black-holing of traffic when packets exceed interface MTU limits. Verify that MTU settings are consistent across your network path, and consider whether jumbo frames or VPN encapsulation overhead is causing packets to exceed interface MTU. If the problem persists under normal load conditions, contact Cisco TAC for further analysis.

Syslogs:

None

----------------------------------------------------------------

policy-params-failed

Unable to create policy parameters

This counter increments when the firewall cannot create a new connection (flow) due to an internal failure during the flow setup process. The system was unable to allocate or initialize the internal structures needed to enforce security policy on the connection. This is a catch-all counter that fires when flow creation fails for reasons other than the more specific drop counters (such as resource exhaustion, ACL denials, or licensing blocks). Common triggers include: transient memory allocation failures during flow setup, internal state inconsistencies in the security context, or race conditions during policy application. In multi-context deployments, this may indicate that the security context does not have a valid policy installed or synchronized to the data plane at the time the connection attempt occurred.

Recommendation:

Check the system logs for errors related to policy installation or memory allocation failures around the time the counter incremented. Verify that the security context has a valid access control policy configured and successfully deployed. In multi-context environments, confirm that all contexts have completed policy synchronization after configuration changes. If the counter increments persistently, check for memory pressure using 'show memory' and 'show blocks'. For transient occurrences (a few drops during configuration changes or system startup), this is typically benign and represents packets that arrived during a brief window when policy was being installed. If drops are sustained or frequent, collect 'show tech-support' and contact Cisco TAC, as this may indicate a software defect or resource exhaustion condition that requires deeper analysis.

Syslogs:

None

----------------------------------------------------------------

prefilter

Blocked by prefilter policy rule

This counter increments when a packet is dropped with the Snort prefilter drop reason. This can happen when traffic matches a prefilter or tunnel rule with the Block action. For plaintext tunnels that match no tunnel rule, it can also happen when the policy's default action is set to 'Block all tunnel traffic'. Prefilter rules match criteria such as interface objects, networks, VLAN tags, and ports; tunnel rules can also match tunnel endpoints and encapsulation protocols such as GRE, IP-in-IP, IPv6-in-IP, and Teredo.

Recommendation:

Use packet tracer with the trace option enabled to identify which prefilter policy rule caused the drop. Review the prefilter policy configuration in FMC to verify that the blocking rule is intentional. Check whether the traffic should be permitted or fast-pathed instead. For tunnel traffic, verify that tunnel rules and the default tunnel action are configured correctly. If the block is unintended, modify the prefilter rule action to Analyze (for further inspection) or Fast Path (to bypass inspection), or adjust the rule match criteria to exclude legitimate traffic.

Syslogs:

None.

----------------------------------------------------------------

punt-no-mem

Punt no memory

The packet was dropped because the system could not allocate the resources needed to send it to the control plane for processing. Packets are sent to the control plane when they require features that cannot be handled in the fast path, such as application inspection, routing protocol processing, or address resolution (ARP/Neighbor Discovery) for unknown next-hop addresses. This counter increments when the allocation of a control plane event structure fails, which can occur due to actual memory exhaustion, control plane queue saturation, or transient resource contention. Common scenarios include high-volume application inspection (such as ESMTP with many concurrent connections), large bursts of traffic to non-existent hosts triggering repeated address resolution attempts, or sustained control plane load from routing protocols or VPN processing. The counter may also increment if the egress interface is down or unavailable when attempting to resolve the next-hop address.

Recommendation:

If the counter increments occasionally and traffic is not impacted, no action is required—transient allocation failures are normal under brief load spikes. If the counter increments persistently or traffic is affected, check overall memory utilization with 'show memory' and 'show memory detail'. If memory is low (less than 10-15% free), identify memory-intensive features or consider a hardware upgrade. If memory is adequate, investigate control plane load: check for high CPU usage, excessive application inspection connections, or traffic patterns that trigger frequent address resolution (such as scanning or traffic to non-existent destinations). For address resolution issues, verify that routing and interface configurations are correct and that next-hop addresses are reachable. Review application inspection policies to ensure they are not processing unnecessary traffic. If the issue persists despite adequate memory and normal control plane load, contact Cisco TAC with the output of 'show asp drop', 'show memory detail', 'show processes cpu-usage sorted', and 'show conn count'.

Syslogs:

None

----------------------------------------------------------------

punt-queue-limit

Punt queue limit exceeded

This counter increments when packets requiring processing by the control plane cannot be queued because the data-path-to-control-plane event queue has reached its maximum depth. The data path forwards most traffic at line rate, but certain packets must be sent to the control plane for handling—such as packets requiring deep inspection, ARP resolution, routing protocol updates, or initial connection setup for stateful features. Each event type (punt, ARP, routing, inspection, high availability) has its own queue with a fixed limit. When traffic patterns generate control-plane events faster than they can be processed, the queue fills and new events are tail-dropped, causing packet loss. This typically occurs during traffic bursts to unresolved destinations, high volumes of new connections requiring inspection, or when the control plane is heavily loaded by other operations. The associated syslog 447001 identifies which specific queue overflowed.

Recommendation:

Use 'show asp event dp-cp' to identify which event queue is experiencing enqueue failures and high depth. Common scenarios: (1) High 'adj-absent' or 'arp-in' failures indicate traffic to many unresolved next-hop addresses—verify routing, check for traffic to non-existent hosts, or apply access lists to block unwanted traffic; consider static ARP entries for legitimate destinations. (2) High 'punt' queue failures during connection setup suggest the control plane cannot keep pace with new session rates—reduce new connection rate, disable unnecessary inspection, or verify the device is not undersized for the traffic load. (3) Persistent queue overflows during normal operation may indicate control-plane CPU exhaustion—check 'show processes cpu-usage' and investigate what is consuming CPU. If drops are transient during traffic spikes and recover quickly, they may be acceptable. Sustained drops indicate a capacity or configuration issue requiring intervention.

Syslogs:

447001

----------------------------------------------------------------

punt-rate-limit

Punt rate limit exceeded

The device drops packets that are being sent to the control plane when the configured rate limit is exceeded. This protection prevents the control plane from being overwhelmed by excessive traffic that requires software processing. The most common traffic type affected is Address Resolution Protocol (ARP) packets, which have a default limit of 500 packets per second per interface. In certain multicast configurations, particularly Protocol Independent Multicast (PIM) bidirectional mode, multicast data traffic may also be subject to rate limiting (typically around 50 packets per second) when it must be punted to the control plane for processing. This can occur when the device is on a shared tree path but does not receive source-specific join messages from downstream peers, or when the Last Hop Router does not trigger Shortest Path Tree switchover.

Recommendation:

For ARP-related drops: Investigate the source of excessive ARP traffic on the affected interface. Common causes include ARP storms from misconfigured devices, network loops, or malicious ARP flooding attacks. You can adjust the ARP rate limit using the 'arp rate-limit' command if legitimate traffic patterns require a higher threshold, though values below the platform default may impact performance. Use 'show arp statistics' to monitor ARP activity. For multicast-related drops: If you are running PIM bidirectional mode and observe this counter incrementing with multicast traffic, verify that your multicast routing configuration is correct and that Rendezvous Point (RP) settings are properly configured. Check whether downstream routers are sending source-specific joins and whether Last Hop Routers are performing Shortest Path Tree switchover as expected. These drops may indicate a software defect in multicast handling; contact Cisco TAC if multicast traffic is being rate-limited unexpectedly. In general, sustained increments of this counter indicate either a network issue requiring investigation or a legitimate traffic spike that may require rate limit adjustment.

Syslogs:

None.

----------------------------------------------------------------

punt_action

Layer 2 Control Plane Event Processing Failure

This counter increments when the device cannot allocate or enqueue control plane events for Layer 2 traffic that requires special processing. This affects protocols that must be sent from the fast path to the control plane for handling, including ARP, PPPoE discovery and session packets, Precision Time Protocol (PTP), and IS-IS frames. The drop occurs when the control plane event queue is full or event allocation fails, typically during traffic bursts when many packets simultaneously require control plane processing. This is most commonly seen with ARP traffic when the device receives a large volume of packets destined to addresses without existing adjacency entries, causing each packet to trigger an ARP resolution request to the control plane. The counter does not reflect Layer 2 ACL policy denies.

Recommendation:

Check control plane CPU utilization and the dataplane-to-control-plane event queue status using 'show asp event dp-cp'. Look for high enqueue failure counts, particularly for 'adj-absent' and 'arp-in' event types. If drops correlate with missing ARP entries during traffic bursts, consider: (1) adding static ARP entries for frequently-accessed next-hop gateways to reduce control plane load, (2) applying access lists to block unwanted traffic that triggers unnecessary ARP resolution, or (3) investigating whether the traffic pattern is legitimate or represents a scanning or flooding attack. Sustained increments of this counter combined with high control plane CPU may indicate the device is overwhelmed by the volume of traffic requiring special handling.

Syslogs:

None.

----------------------------------------------------------------

queue-removed

Packets dropped during rate limiter reconfiguration

This counter increments when packets queued in a rate limiter are dropped because the rate limiter configuration was changed or removed. Rate limiters are used in several contexts: class-based quality-of-service (QoS) policies that shape traffic to specific rates, automatic link-speed-based rate limiting on certain hardware platforms, and high-availability or clustering control-plane traffic rate limiting. When you modify or remove a QoS policy, change interface speed settings, or reconfigure high-availability parameters, the system must replace the existing rate limiter with a new one (or remove it entirely). Any packets still waiting in the old rate limiter's queue at that moment are dropped rather than transferred to the new limiter, and this counter increments for each dropped packet. This behavior also occurs during automatic link speed changes on platforms that use hardware-based rate limiting to match interface speeds.

Recommendation:

This counter incrementing during QoS policy changes, interface speed reconfigurations, or high-availability setup changes is expected and normal. The dropped packets represent in-flight traffic that was queued at the moment of the configuration change. To minimize the impact, apply QoS or interface configuration changes during maintenance windows when traffic levels are low. If you see this counter incrementing when no configuration changes have been made, verify that interface link speeds are stable (flapping links can trigger automatic rate limiter adjustments) and check for any automated configuration management systems that might be making changes. On Firepower Threat Defense, avoid using the priority-queue command on port-channel interfaces, as it can cause unrelated packet drops (see defect CSCwf47227). If the counter increments continuously without any configuration activity or link state changes, contact Cisco TAC for further investigation.

Syslogs:

None.

----------------------------------------------------------------

quic-initial-malformed-pkt

QUIC Initial packet dropped due to insufficient size

The firewall dropped a QUIC Initial packet because its UDP payload was smaller than the required 1200 bytes. QUIC protocol specifications mandate that Initial packets—the first packets in a QUIC connection handshake—must be at least 1200 bytes to prevent amplification attacks and ensure proper path MTU discovery. This counter increments when the QUIC inspection feature detects an undersized Initial packet during connection establishment, before the connection reaches the half-open state. Legitimate QUIC clients pad Initial packets to meet this requirement; undersized packets typically indicate non-compliant implementations, malformed traffic, or potential attack attempts.

Recommendation:

This drop is a security enforcement and is typically benign—it protects against malformed or malicious QUIC traffic. If this counter increments frequently for legitimate applications, investigate whether the client application or library is QUIC-compliant (RFC 9000). Check the source IP addresses to determine if specific clients are affected. If a known application is generating undersized Initial packets, contact the application vendor for an update. No configuration change is needed on the firewall; this validation is part of the QUIC inspection feature and cannot be disabled independently. If QUIC inspection itself is causing issues, you can bypass it by disabling SSL/TLS decryption for the affected traffic, though this will prevent deep inspection of QUIC connections.

Syslogs:

None

----------------------------------------------------------------

quic-malformed-pkt

QUIC Malformed Packet Received

This counter checks whether the QUIC packet, header, or combined packet overhead exceeds the 2048-byte processing limit. The firewall drops these packets during the decryption and validation phase of QUIC proxy processing. Malformed packets include those with Initial packets smaller than the required 1200-byte minimum size, or packets with invalid field combinations that prevent proper decryption. This occurs only when QUIC inspection is enabled and the firewall is acting as a man-in-the-middle proxy to decrypt and inspect QUIC traffic between clients and servers.

Recommendation:

Low, steady counts are normal and indicate the firewall is correctly rejecting invalid QUIC packets from the network. Investigate if you see sudden spikes or sustained high rates, which may indicate a misconfigured QUIC client, an attack attempt, or network corruption affecting QUIC traffic. Verify that legitimate QUIC applications are functioning correctly. If specific applications are affected, capture packets to determine whether the client is sending non-compliant QUIC packets or if network conditions are corrupting traffic. This counter only increments when QUIC inspection is enabled; if QUIC traffic is not being inspected, this counter will remain at zero.

Syslogs:

None

----------------------------------------------------------------

quic-proxy-0rtt-pkt-drop

QUIC 0-RTT Packet Dropped

This counter increments when the QUIC inspection proxy receives a 0-RTT (zero round-trip time) packet from a client attempting to send early data during connection resumption. QUIC 0-RTT allows clients to send application data in the first flight of a resumed connection, before the TLS 1.3 handshake completes. The QUIC inspection feature does not support 0-RTT packets and drops them to maintain inspection coverage. This occurs when a QUIC client attempts session resumption with early data enabled, typically seen with browsers or applications that have previously connected to the same server and are trying to reduce connection latency. The connection will fall back to a standard 1-RTT handshake.

Recommendation:

This drop is by design and indicates normal operation when QUIC inspection is enabled. The client will automatically retry the connection using a standard 1-RTT handshake, which the firewall can fully inspect. No action is required unless you observe connection failures. If applications require 0-RTT support and cannot tolerate the fallback behavior, you may need to exclude those flows from QUIC inspection or disable QUIC inspection for the affected traffic. Monitor the counter to understand how frequently clients attempt 0-RTT resumption in your environment. Persistent high counts may indicate applications that heavily rely on session resumption for performance.

Syslogs:

None

----------------------------------------------------------------

quic-proxy-alloc-fail

QUIC Proxy Metadata Allocation Failed

The firewall dropped a QUIC packet because it could not allocate internal metadata required to process the packet through the QUIC inspection proxy. This occurs when the firewall is processing QUIC traffic with deep packet inspection enabled and attempts to attach tracking information to each packet for decryption and re-encryption. The allocation failure indicates memory pressure in the packet processing subsystem, typically during high connection rates or when handling many concurrent QUIC flows. This counter applies only to FTD platforms with QUIC offload enabled and an SSL/TLS inspection policy applied to QUIC traffic.

Recommendation:

Check overall system memory utilization and connection rates. Review the number of active QUIC flows and consider whether the inspection policy can be scoped more narrowly. If this counter increments frequently, the device may be undersized for the QUIC traffic volume, or a memory leak may be present. Temporary spikes during traffic bursts are typically benign and self-correcting. If sustained, consider disabling QUIC inspection for non-critical traffic classes, increasing system resources, or contacting Cisco TAC if memory utilization appears normal but drops persist.

Syslogs:

None

----------------------------------------------------------------

quic-proxy-destroy-tx-queue-drop

QUIC proxy retransmission queue cleanup

This counter increments when the device tears down a QUIC connection's retransmission queue and drops any packets still waiting in that queue. The QUIC proxy maintains separate retransmission queues for Initial and Handshake packets during connection establishment. When a QUIC connection is closed—whether due to normal termination, embryonic connection timeout, handshake completion, security validation failure, or flow cleanup—the device drains these queues and drops any unacknowledged packets that were awaiting retransmission. This is normal cleanup behavior during connection teardown and does not indicate a problem with the connection itself.

Recommendation:

This counter reflects routine connection cleanup and is expected during normal QUIC traffic patterns. Incrementing values indicate QUIC connections are being torn down while packets remain in the retransmission queues, which commonly occurs when: (1) embryonic connections time out before completing the handshake, (2) connections are closed by either endpoint before all handshake packets are acknowledged, (3) the device detects a security issue and forces connection closure, or (4) flows are administratively cleared. If this counter grows rapidly alongside other QUIC error counters, investigate whether handshake timeouts or connection establishment failures are occurring. Use 'show asp drop' to correlate with other QUIC-related drops, and 'show conn protocol udp' to examine active QUIC connection states. No action is required for moderate increments during normal operation.

Syslogs:

None

----------------------------------------------------------------

quic-proxy-invalid-cid

QUIC inspection dropped packet due to connection ID validation failure

This counter increments when the QUIC inspection proxy cannot extract or validate the Destination Connection ID (DCID) from a QUIC Initial packet. The DCID is required to derive the cryptographic keys needed to decrypt and inspect QUIC traffic. This drop occurs during the initial handshake phase when the device attempts to intercept QUIC connections for deep packet inspection. Common causes include malformed QUIC packets, connection IDs that exceed protocol length limits (20 bytes), packets with invalid header structures, or QUIC implementations that do not conform to the expected format. This counter is specific to FTD platforms with QUIC inspection enabled and only applies to Initial packets in the QUIC handshake sequence.

Recommendation:

Verify that QUIC inspection is intentionally enabled in your access control policy. If QUIC inspection is required, check whether the client or server QUIC implementation uses non-standard connection ID formats or lengths. Review packet captures to confirm the QUIC Initial packets contain valid, properly formatted DCIDs within the 20-byte limit. If drops persist with legitimate QUIC traffic from known applications (such as Google services, Microsoft Teams, or other QUIC-based applications), consider bypassing QUIC inspection for those specific flows using prefilter rules or disabling QUIC inspection entirely if deep inspection is not required. Note that a critical security vulnerability (CSCwu42642) related to unchecked connection ID lengths was fixed in recent releases; ensure your software is up to date. Contact Cisco TAC if drops occur with standard QUIC implementations after verifying packet format and software version.

Syslogs:

None

----------------------------------------------------------------

quic-proxy-large-reassembly-packet

QUIC Proxy Large Reassembly Packet

This counter increments when the QUIC inspection proxy receives an IP-fragmented packet that, after a successful reassembly, exceeds the internal processing buffer size limit (2048 bytes). This occurs during QUIC connection establishment when large Initial packets (typically containing ClientHello or ServerHello messages with certificates or extensions) arrive fragmented at the IP layer and the reassembled size is too large for the proxy to process. The packet is dropped to prevent buffer overruns in the QUIC decryption and re-encryption pipeline. This condition is most commonly seen with QUIC connections that negotiate large TLS certificates or use extensive TLS extensions, combined with network paths that fragment UDP datagrams carrying QUIC Initial packets.

Recommendation:

If this counter is incrementing, verify that QUIC clients and servers are not sending excessively large Initial packets that require IP fragmentation. Check the MTU configuration on interfaces carrying QUIC traffic—QUIC is designed to avoid IP fragmentation through path MTU discovery, and fragmented Initial packets may indicate MTU mismatches or misconfigured endpoints. Review certificate sizes on servers accessed via QUIC; consider using shorter certificate chains or ECDSA certificates instead of RSA to reduce handshake message sizes. If the issue persists and affects legitimate traffic, contact Cisco TAC with packet captures showing the fragmented QUIC Initial packets and the output of 'show asp drop' and 'show snort quic-offload statistics'. Note that this drop was addressed in defect CSCwm50000 for certain fragmentation scenarios; ensure your software version includes this fix.

Syslogs:

None

----------------------------------------------------------------

quic-proxy-non-quic-pkt-drop

QUIC Proxy: Non-QUIC packet dropped during inspection

This counter increments when QUIC inspection is enabled on a flow and a UDP packet arrives that does not conform to the QUIC protocol format. The inspection engine validates each packet to determine its QUIC packet type (Initial, Handshake, 0-RTT, 1-RTT, Version Negotiation, or Retry). When validation fails, the packet is dropped because it cannot be classified as a valid QUIC packet. This typically occurs when non-QUIC UDP traffic is incorrectly identified as QUIC, when a QUIC connection receives malformed or corrupted packets, or when an application switches protocols mid-flow. This can also occur due to failures in packet-recognition, crypto, decode, integrity, version, and connection-states. The drop protects the inspection engine from processing invalid data that could cause errors during decryption or inspection.

Recommendation:

Review the traffic pattern to determine why non-QUIC packets are arriving on a QUIC-inspected flow. Check if the application is using the same UDP 5-tuple for both QUIC and non-QUIC traffic, which violates protocol expectations. Verify that QUIC inspection is correctly configured and applied only to legitimate QUIC traffic. If the application legitimately switches protocols or sends non-QUIC packets on the same connection, consider adjusting the inspection policy or using more specific traffic classification. Capture packets on both sides of the firewall to identify the source of the malformed traffic. If drops are frequent and affecting legitimate traffic, contact Cisco TAC with packet captures and the output of 'show asp drop' and 'show service-policy inspect quic'.

Syslogs:

None

----------------------------------------------------------------

quic-proxy-null-flow-drop

QUIC Proxy Missing Flow Context

This counter increments when the QUIC inspection proxy receives a packet but cannot locate the required flow state or its paired bidirectional flow. QUIC inspection on FTD operates as a man-in-the-middle proxy that decrypts, inspects, and re-encrypts QUIC traffic between clients and servers. This requires maintaining paired flow structures (client-to-server and server-to-client) with associated proxy contexts. The drop occurs when a packet arrives for QUIC proxy processing but the flow lookup returns no flow, or the flow exists but lacks its required paired flow. Common triggers include: packets arriving during or immediately after a high-availability failover (when the newly active unit receives traffic for flows created while it was standby, before proxy structures are fully synchronized); race conditions during flow teardown where packets arrive after one direction's flow has been freed; QUIC inspection being disabled mid-connection; or internal metadata corruption. This is specific to FTD platforms with QUIC hardware offload enabled and an SSL decryption policy applied to QUIC traffic.

Recommendation:

Check whether the device recently experienced a failover event—if so, these drops are expected during the transition period and should cease once flow state stabilizes (typically within seconds). Verify QUIC inspection is consistently enabled with 'show running-config ssl' and confirm the SSL policy includes QUIC traffic; toggling QUIC inspection on/off during active connections will cause this drop. Review 'show conn detail' for the affected 5-tuple to determine if flows exist for both directions—missing paired flows indicate incomplete connection setup. If drops persist without failover and flows appear healthy, collect 'show asp drop' output over time to quantify the rate, enable 'debug packet-module quic-proxy' (with caution—high overhead), and capture packets to correlate drops with specific QUIC connection phases. For ongoing drops in a stable environment, contact TAC with the debug output, packet captures showing the dropped QUIC packets, and 'show tech' to investigate potential flow synchronization or proxy allocation issues.

Syslogs:

None.

----------------------------------------------------------------

quic-proxy-null-flow-drop-after-fover

QUIC Proxy Missing State After Failover

This counter increments when the device receives a QUIC packet for a connection that exists in the flow table but lacks the necessary internal proxy state structures. This occurs specifically after a high-availability failover event when the device transitions from standby to active. During failover, QUIC connections that were created while the device was in standby mode may have flow entries but missing proxy context (encryption keys, connection state, tracking data). When packets arrive for these incomplete connections, the device cannot process them and must drop the traffic. The affected flow is automatically aged out with a one-second timeout to clean up the incomplete state.

Recommendation:

This counter is expected during high-availability failover transitions and indicates normal cleanup of connections that cannot be fully reconstructed on the new active unit. QUIC hardware offload state is not synchronized between HA peers, so existing QUIC connections will be disrupted during failover and must be re-established by the endpoints. If this counter increments outside of a failover event, or continues to increment significantly after failover completes, verify that QUIC hardware offload is properly enabled on the device and check for any configuration mismatches between HA peers. Monitor whether new QUIC connections establish successfully after failover; if they do, the drops are limited to pre-existing flows and require no action. Persistent issues may indicate a problem with QUIC proxy initialization and should be escalated to Cisco TAC.

Syslogs:

None

----------------------------------------------------------------

quic-proxy-residue-packet

QUIC Proxy Residue Packet

The firewall received a QUIC packet for which no connection exists, but the packet is not an Initial packet type. QUIC inspection requires the Initial packet (which contains the TLS 1.3 handshake) to establish the inspection session and decrypt subsequent traffic. When a non-Initial packet (such as Handshake, 0-RTT, or 1-RTT application data packets) arrives before the connection is established, the firewall cannot process it and drops the packet. This typically occurs when the Initial packet was lost or dropped, when packets arrive out of order during connection establishment, or when the firewall is inserted mid-connection after the QUIC handshake has already begun. The counter tracks these residue packets that cannot be associated with an existing inspection session.

Recommendation:

This drop is expected behavior when QUIC packets arrive out of sequence or when the firewall misses the connection establishment. If this counter increments frequently, verify that Initial packets are reaching the firewall (check for packet loss or asymmetric routing during connection setup). Ensure the firewall is in the path for the complete QUIC handshake, not inserted mid-connection. Review any access control lists or rate limiting that might be dropping Initial packets while allowing subsequent packets through. If the application retransmits the Initial packet, the connection should establish successfully on retry. Persistent issues may indicate network path problems or QUIC version compatibility issues between the client and server.

Syslogs:

None

----------------------------------------------------------------

rate-exceeded

QoS rate limit exceeded

This counter increments when traffic exceeds the rate or burst threshold configured in a QoS policing policy applied to an interface. Policing is configured using the 'police input' or 'police output' commands within a service policy and enforces a maximum bit rate (conform rate) and instantaneous burst size (conform burst). When incoming or outgoing traffic on an interface exceeds these thresholds, packets are dropped and this counter increments. The rate limiter uses a token bucket algorithm that allows short bursts up to the configured burst size while enforcing the average rate over time. For VPN traffic, the rate calculation includes IPsec encapsulation overhead to ensure accurate enforcement of the configured limits. Each dropped packet increments this counter by one.

Recommendation:

Use 'show service-policy' to identify which interface and traffic class is experiencing drops, and review the configured rate and burst values. Compare the 'offered rate' against the 'conform rate' to determine if the limit is appropriately sized for the traffic pattern. If drops are unexpected, verify that the configured rate matches your intended bandwidth limit and that the burst size accommodates legitimate traffic bursts. For VPN traffic, ensure rate limits account for encryption overhead (typically 50-100 bytes per packet depending on the IPsec configuration). If the rate limit is intentional (for example, to enforce bandwidth policies or protect against traffic floods), these drops are expected behavior. For FTD deployments, you can correlate drops to specific QoS rules using 'show conn flow-rule qos <rule-id>'. If rate limits are not configured but drops still occur, check for platform-specific throughput licensing limits on virtual appliances (FTDv, ASAv) which also use this counter.

Syslogs:

None.

----------------------------------------------------------------

reason-info

Packet trace information captured from Snort inspection

This counter increments when the threat defense engine sends detailed inspection trace data back to the data path for inclusion in packet-tracer or capture-with-trace output. It is not a packet drop counter. When packet-tracer is active or capture with trace is enabled, the inspection engine attaches diagnostic information to its verdict messages, including the specific reason code for the verdict, preprocessor actions taken, and rule evaluation details. The data path receives this trace information and stores it in the packet tracer buffer so it can be displayed in the packet-tracer output or included in capture files. This mechanism provides visibility into what the inspection engine evaluated and why it made specific allow or block decisions. The counter reflects normal diagnostic operation when packet tracing features are in use.

Recommendation:

This counter is informational only and indicates that packet trace data collection is working as designed. It increments whenever packet-tracer commands are run or when capture with trace is active on interfaces with threat defense inspection enabled. A non-zero value is expected and normal when using these diagnostic features. No action is required. If you are not actively using packet-tracer or capture-with-trace and this counter is incrementing, verify that no diagnostic captures or traces are inadvertently left running, as trace data collection has a minor performance impact.

Syslogs:

None.

----------------------------------------------------------------

reinject-fail

Packet reinjection work queue full

This counter increments when the appliance cannot reinject a packet back into the data path after control-plane processing because the work queue is full or unavailable. Reinjection occurs when packets are temporarily diverted to the control plane for inspection or modification and then returned to the data path for forwarding. Common scenarios include DNS packets inspected by Umbrella or DNScrypt, packets held pending ARP resolution, and ICMP error messages generated by the appliance (such as fragmentation-needed responses). The drop indicates that the internal work queue used to schedule the reinjected packet onto the correct processing core reached capacity or became unavailable, preventing the packet from continuing through the forwarding pipeline.

Recommendation:

Occasional increments are typically benign and indicate transient congestion in the internal packet scheduling system. If this counter increases steadily, investigate whether the appliance is experiencing high CPU utilization or processing load that prevents timely consumption of queued work items. Check for features that frequently punt packets to the control plane, such as DNS inspection with Umbrella redirection, DNScrypt encryption, or high rates of ARP resolution on busy networks. Review CPU usage with 'show cpu usage' and consider whether traffic patterns (such as DNS query floods or frequent ARP requests) are overwhelming the control plane. If drops correlate with application failures, verify that connection timeouts are appropriate for the traffic type. Contact Cisco TAC if drops persist under normal load conditions or if they correlate with system instability.

Syslogs:

None.

----------------------------------------------------------------

reputation

Blocked by Security Intelligence IP reputation

This counter increments when a packet is dropped because its source or destination IP address matches an entry in a configured Security Intelligence IP reputation blacklist. Security Intelligence provides early-stage threat filtering by comparing packet IP addresses against threat intelligence feeds (from Talos or custom lists) before more resource-intensive inspection occurs. The decision to block is made during the reputation inspection phase based on the IP reputation lists configured in your access control policy. Both the source and destination IP addresses are evaluated, and in some cases auxiliary IP addresses (such as those in HTTP X-Forwarded-For headers) are also checked. When a match is found on a blacklist configured with a 'block' action, the packet is dropped and the entire session is blocked.

Recommendation:

This drop is typically intentional and indicates that Security Intelligence is working as designed to block traffic from known malicious IP addresses. To investigate: (1) Use packet-tracer to identify which specific IP address triggered the block and which reputation list matched. (2) Review your Security Intelligence configuration in the access control policy to verify the configured IP blacklists and their sources. (3) Check the Security Intelligence feed download status to ensure threat intelligence feeds are up to date. (4) If legitimate traffic is being blocked, add the IP address to a Security Intelligence whitelist (Do-Not-Block list) or adjust your reputation list configuration. (5) If you want to observe matches without blocking, change the action from 'block' to 'monitor' for specific lists. Review the iprep.log file in troubleshooting bundles to verify that reputation feeds are downloading successfully.

Syslogs:

None.

----------------------------------------------------------------

rm-conn-limit

Connection limit reached

The device has reached the maximum number of concurrent connections allowed and rejected a new connection attempt. In single-mode deployments, this occurs when the system-wide connection limit is reached. In multi-context mode, this counter increments when either a per-context limit or the system-wide limit is exceeded. The limit enforcement occurs before allocating memory for the new connection. When a limit is reached, the system first attempts to reclaim preemptable connections (such as embryonic or idle connections eligible for removal) before rejecting the new connection. Management traffic to or from the device itself bypasses these limits and will not trigger this counter.

Recommendation:

Use 'show resource usage' to view current connection counts, peak usage, configured limits, and the number of denied connections for each context. Use 'show resource usage system' to view system-wide resource consumption in multi-context deployments. If legitimate traffic is being dropped, consider increasing the connection limit using 'limit-resource conns' in the appropriate resource class (multi-context mode) or adjusting platform-level limits. In multi-context environments, verify that both per-context and system-wide limits are appropriately sized - a context may be denied even if its own limit has not been reached if the system limit is exhausted. If drops occur well below configured limits, verify you are running a recent software version as older releases had accounting bugs that caused premature limit enforcement. Monitor for syslog 321001 which accompanies these drops. If connection exhaustion is due to attack traffic or connection leaks, investigate using 'show conn' and 'show local-host' to identify the source of excessive connections.

Syslogs:

321001

----------------------------------------------------------------

rm-conn-rate-limit

Connection rate limit exceeded

The device dropped a new connection attempt because the rate of new connections per second exceeded the configured limit. This limit protects the device from connection floods and ensures fair resource allocation across security contexts in multi-context deployments. The limit is enforced separately at two levels: per-context (in multi-context mode) and system-wide. When either threshold is exceeded, new connection attempts are denied until the rate falls below the limit. This is a rate limit (connections per second), not a concurrent connection count limit. The counter increments for each connection attempt that arrives while the rate limit is active.

Recommendation:

Use 'show resource usage' to view per-context resource limits and denied connection counts. In multi-context mode, use 'show resource usage system' to view system-wide limits. Check the 'Denied' column to identify which contexts are hitting rate limits. If legitimate traffic is being dropped, consider increasing the connection rate limit using 'limit-resource rate' in class configuration mode (multi-context) or adjusting system-wide rate limits. Review syslog message 321002 to identify when rate limit events occur and correlate with traffic patterns. If drops occur during expected traffic bursts (application startup, failover events), the current limit may be too restrictive for your traffic profile. In some cases, modifying connection resource limits can trigger unexpected rate limit enforcement; if this occurs, remove and re-apply the limit configuration. If rate limits are being hit continuously under normal load, investigate whether the device is under attack or if the platform is undersized for the traffic volume.

Syslogs:

321002

----------------------------------------------------------------

rpf-violated

Reverse Path Forwarding (RPF) Check Failed

This counter increments when the firewall receives a packet that fails Reverse Path Forwarding (RPF) validation. RPF is an anti-spoofing mechanism enabled with the 'ip verify reverse-path' interface command. When a packet arrives, the firewall performs a route lookup on the source IP address and verifies that the routing table would send return traffic back out the same interface where the packet was received. If the interfaces don't match, the packet is dropped as potentially spoofed. This counter tracks both unicast and multicast RPF failures. Common legitimate causes include asymmetric routing (where forward and return paths differ), Policy-Based Routing (PBR) configurations that redirect traffic without corresponding return routes, VPN split-tunneling with 'tunnelled' static routes, and multicast traffic arriving on interfaces without proper multicast routing state. The firewall exempts certain traffic from RPF checks: IPsec encrypted packets, DHCP/BOOTP broadcasts, BFD echo packets, and IPv6 link-local traffic.

Recommendation:

First, verify whether the traffic is legitimate or spoofed by examining the source IP in syslog 106021. For legitimate traffic: (1) If you have asymmetric routing by design (common in clustered or load-balanced environments), either disable 'ip verify reverse-path' on the affected interface or add a static route for the source network pointing to the ingress interface—the route doesn't need to be used for forwarding but satisfies the RPF check. (2) For Policy-Based Routing scenarios, ensure return path routes exist even if PBR handles the forward direction. (3) For multicast traffic, verify that PIM is properly configured and multicast routes (mroutes) are established; use 'show mroute' to check state. (4) In clustering deployments with PBR, this is a known interaction (CSCus82344)—add static routes as a workaround. If the source IP is external and unexpected, investigate potential IP spoofing. The feature is working as designed to protect against spoofed traffic; drops are only problematic when legitimate asymmetric routing exists in your topology.

Syslogs:

106021

----------------------------------------------------------------

rule-transaction-in-progress

Initial rule compilation in progress (transactional commit mode)

The firewall is compiling access control rules during system or security context initialization while transactional commit mode is enabled. During this initial compilation phase, all through-the-box traffic is temporarily dropped to prevent packets from being classified against an incomplete or inconsistent rule set. Management traffic to and from the firewall itself continues to be processed normally. This condition occurs when the 'asp rule-engine transactional-commit access-group' feature is configured and the device is starting up, a security context is initializing, or after certain failover events. The compilation duration depends on the complexity and number of configured rules (access lists, NAT rules, object groups).

Recommendation:

This is a normal, temporary condition during initialization. The drops should cease automatically once rule compilation completes, typically within seconds to a few minutes depending on configuration size. Monitor compilation progress using 'show process cpu-usage non-zero sorted | include tmatch' to verify the compilation thread is running and eventually completes. If drops persist for an extended period (more than 5-10 minutes) or occur repeatedly outside of initialization events, check for: (1) extremely large or complex access list configurations that may benefit from object-group-search optimization, (2) failover timing issues where a standby unit is promoted to active before compilation finishes—wait for 'Standby Ready' state and verify compilation is complete before performing manual failovers, (3) known defects in older software versions (fixed in 9.12.4.10+, 9.14.2.4+, 9.16.4.67+). If drops continue indefinitely after initialization, contact Cisco TAC as this may indicate a software defect.

Syslogs:

780001 (compilation started), 780002 (compilation finished)

----------------------------------------------------------------

safe-search

Traffic blocked by Safe Search enforcement policy

This counter increments when traffic to a search engine is dropped due to Safe Search enforcement configured in an access control rule. Safe Search is a feature that enforces safe search filtering on supported search engines (Google, Bing, Yahoo, YouTube, Yandex, and others) by modifying HTTP headers or URLs. When Safe Search is enabled in an access control rule, you can configure an action for unsupported search engines: allow, block, or block-with-reset. This counter increments when the configured action is block or block-with-reset and traffic matches an application identified as a search engine that does not support Safe Search enforcement. The feature requires application identification to detect search engine traffic and may require SSL decryption if the traffic is encrypted.

Recommendation:

Review your access control policy configuration in Firewall Management Center to verify Safe Search settings. Check which action is configured for unsupported search engines in the rule that matched the traffic. If legitimate traffic is being blocked, consider: (1) changing the unsupported search engine action from block to allow, (2) creating a more specific access control rule above the Safe Search rule to permit the blocked traffic, or (3) using URL filtering or application overrides to exclude specific sites that are incorrectly classified as search engines. Use packet tracer or enable connection event logging to identify which applications are triggering the block. Note that some applications may be incorrectly tagged as search engines in the application database; if this occurs, create an exception rule or contact TAC if the classification appears incorrect.

Syslogs:

None

----------------------------------------------------------------

same-physical-interface

Same input and output physical interface

Traffic was dropped because the routing or NAT policy would have sent the packet back out the same physical interface it arrived on. This counter is specific to the ASA 1000V (Virtual Security Gateway) platform, which does not support hairpin routing where a packet enters and exits through the same physical interface. On ASA 1000V, security profiles are mapped to physical interfaces, and the platform architecture prevents traffic from looping back through the same physical interface. This typically occurs when NAT translation or routing decisions direct return traffic to the same interface that received the original packet.

Recommendation:

This counter only appears on ASA 1000V deployments. Review your NAT and routing configuration to ensure traffic flows follow a proper path through different interfaces. Use the 'packet-tracer' command to simulate the traffic flow and identify which security profile mappings are being used. Check 'show running-config service-interface' to verify the association between physical interfaces and configured security profiles. Adjust NAT rules or routing policies to ensure traffic ingresses on one interface and egresses on a different interface. If you need hairpin or U-turn traffic flows, consider redesigning the network topology or using a different platform that supports same-interface routing.

Syslogs:

None.

----------------------------------------------------------------

sctp queue-limit

SCTP out-of-order queue limit exceeded

The firewall drops an SCTP DATA chunk because the per-stream reorder queue has reached its maximum capacity. SCTP supports multiple independent streams within a single association, and each stream maintains its own queue to buffer out-of-sequence DATA chunks while waiting for missing sequence numbers to arrive. When packets arrive out of order—due to network congestion, routing changes, or packet loss—the firewall queues them until the missing chunks arrive or a 30-second timeout expires. This counter increments when a stream already has the maximum number of queued out-of-order chunks (default limit: 50 per stream) and a new out-of-sequence chunk arrives. The new chunk is dropped to prevent memory exhaustion. This protection mechanism was introduced to defend against memory exhaustion attacks and handle pathological network conditions.

Recommendation:

This drop typically indicates significant packet reordering or loss on the network path carrying SCTP traffic. Investigate the network between SCTP endpoints for congestion, routing instability, or asymmetric paths. Check for high latency or jitter on the link. If the SCTP application uses many parallel streams and the network has moderate packet loss, legitimate traffic may trigger this limit. In such cases, work with the application vendor to reduce the number of concurrent streams or implement application-layer retransmission. If drops are persistent and affecting service, capture traffic on both sides of the firewall to determine whether reordering is occurring before or after the firewall. Note that a separate global limit restricts the total number of streams with active reorder queues (64 per CPU core); if that limit is reached first, you will see a different drop counter (sctp reorder-stream-limit). This counter specifically indicates per-stream queue exhaustion.

Syslogs:

None

----------------------------------------------------------------

sctp-abort-chunk-unexpected

SCTP ABORT chunk received with invalid bundling

The firewall received an SCTP packet containing an ABORT chunk bundled with other chunks in a way that violates SCTP protocol rules (RFC 4960). SCTP ABORT chunks may only be bundled with AUTHENTICATION chunks; bundling ABORT with other control or data chunks is not permitted. This drop protects against malformed or malicious SCTP traffic that does not conform to the protocol specification. The counter increments during SCTP inspection when the packet validation detects an ABORT chunk in an invalid chunk combination.

Recommendation:

This drop typically indicates a protocol violation by one of the SCTP endpoints or intermediate network equipment. Verify that both SCTP endpoints are RFC 4960 compliant and properly implemented. If the traffic is legitimate, check for:

• Middlebox interference or SCTP-unaware NAT devices that may be corrupting SCTP packets
• Misconfigured SCTP stacks on endpoints that bundle chunks incorrectly
• Potential security scanning or malformed attack traffic

Capture the dropped packets to examine the exact chunk bundling. If the SCTP endpoints are known to be compliant and the drops are impacting legitimate signaling traffic (such as Diameter or M3UA), contact Cisco TAC with packet captures showing the ABORT chunk bundling pattern.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-cookie-ack-in-invalid-state

SCTP COOKIE-ACK received in wrong association state

The firewall dropped an SCTP COOKIE-ACK chunk because the association was not in the expected state. During normal SCTP connection establishment, the four-way handshake proceeds as INIT, INIT-ACK, COOKIE-ECHO, then COOKIE-ACK. The firewall expects to receive the COOKIE-ACK only when the local endpoint is in the COOKIE-ECHOED state (after sending the COOKIE-ECHO). This counter increments when a COOKIE-ACK arrives in any other state, indicating either out-of-sequence packets, retransmissions after the association has already transitioned to established, or protocol violations by one of the endpoints. This drop enforces proper SCTP state machine sequencing and prevents malformed handshakes from completing.

Recommendation:

This drop typically indicates timing issues or retransmissions during SCTP association setup. Check whether SCTP associations are successfully establishing despite the drops—if associations complete normally, the drops may be benign retransmissions arriving after the handshake finished. If associations fail to establish, verify that SCTP inspection is properly configured and that network delays or packet loss are not causing excessive retransmissions. Review the output of 'show sctp' to see current association states and 'show service-policy inspect sctp' to confirm inspection is active. If drops persist and prevent associations from forming, capture packets on both sides of the firewall to identify whether endpoints are sending duplicate or out-of-order handshake messages. In multi-homed SCTP deployments, ensure all endpoint addresses are reachable and NAT configurations (if present) are not interfering with the handshake sequence.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-cookie-ack-no-assoc

SCTP COOKIE-ACK received without matching association

The firewall received an SCTP COOKIE-ACK chunk but could not find the corresponding association state. The COOKIE-ACK is the final message in the SCTP four-way handshake (INIT, INIT-ACK, COOKIE-ECHO, COOKIE-ACK) that completes association establishment. This drop occurs when the association state has been removed before the COOKIE-ACK arrives. Common causes include: the association already completed establishment and the COOKIE-ACK is a delayed retransmission; the association timed out during the handshake; the firewall restarted or failed over between receiving the COOKIE-ECHO and the COOKIE-ACK; or packets arrived out of order. This counter may also increment during asymmetric routing scenarios where the firewall sees only the COOKIE-ACK without having seen the earlier handshake messages.

Recommendation:

Review SCTP association establishment patterns in your environment. If this counter increments occasionally, it typically indicates normal retransmissions or timing variations in the SCTP handshake and can be ignored. If the counter increments frequently, investigate: (1) whether SCTP clients are retransmitting COOKIE-ACK messages after associations have already been established, (2) whether SCTP handshake timeouts are too short for your network latency, (3) whether asymmetric routing is causing the firewall to see only partial handshake flows, or (4) whether high-availability failover or firewall reloads are occurring during active SCTP sessions. Use 'show sctp' to verify that legitimate SCTP associations are successfully reaching the ESTABLISHED state. If associations are failing to establish, collect packet captures to determine whether the complete four-way handshake is traversing the firewall.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-cookie-echo-cookie-len

SCTP COOKIE-ECHO chunk contains cookie with mismatched length

The firewall drops an SCTP COOKIE-ECHO chunk because the cookie length does not match the length recorded during the earlier INIT-ACK exchange. During SCTP's four-way handshake, the server sends an INIT-ACK containing a STATE-COOKIE parameter; the firewall records this cookie's length. When the client echoes the cookie back in a COOKIE-ECHO chunk (step 3 of the handshake), the firewall validates that the cookie length is unchanged. This counter increments when the lengths differ, indicating the cookie was modified, truncated, or corrupted in transit—or that the COOKIE-ECHO does not correspond to the tracked association. This validation protects against protocol attacks, cookie tampering, and malformed handshakes. SCTP is commonly used for signaling protocols such as Diameter (AAA) and M3UA (SS7 over IP).

Recommendation:

This drop typically indicates a protocol violation or network issue. Verify that no middlebox between the SCTP endpoints is modifying packet payloads. Check for MTU mismatches or fragmentation issues that could corrupt the cookie. If the client is retransmitting a stale COOKIE-ECHO from an earlier association attempt, the firewall may have already cleared the saved cookie length; ensure clients are not caching cookies across connection attempts. Review SCTP inspection configuration with 'show service-policy' and 'show sctp' to confirm the association state. If drops persist and the SCTP endpoints are known-good, capture packets on both sides of the firewall to identify where the cookie is being altered. For legitimate traffic experiencing this issue, contact Cisco TAC with packet captures and 'show asp drop' output.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-cookie-echo-in-close

SCTP COOKIE-ECHO received when association is closed

The firewall dropped an SCTP packet containing a COOKIE-ECHO chunk because the association was in CLOSED state. COOKIE-ECHO is the third step of the SCTP four-way handshake, sent by the client after receiving the server's INIT-ACK. This drop indicates the client is attempting to complete a handshake for an association the firewall believes is already closed or never existed. Common causes include: the association timed out or was torn down before the COOKIE-ECHO arrived; the client is retransmitting a COOKIE-ECHO from a previous connection attempt after the firewall already closed the association; asymmetric routing where the firewall did not see the INIT or INIT-ACK that would have created the association; or the client is sending malformed or replayed SCTP traffic. This counter does not increment during high-availability failover recovery, where the firewall temporarily allows COOKIE-ECHO in CLOSED state to re-establish associations synchronized from the peer unit.

Recommendation:

Review SCTP association timeouts if legitimate traffic is being dropped—associations may be closing too quickly for slow clients or high-latency networks. Verify symmetric routing for SCTP traffic so the firewall sees all four handshake steps (INIT, INIT-ACK, COOKIE-ECHO, COOKIE-ACK). Check for retransmission storms or misbehaving SCTP clients sending COOKIE-ECHO without proper INIT exchange. Use 'show sctp' to view active associations and their states, and 'show service-policy inspect sctp' to confirm inspection is enabled and view drop counters. If drops occur during normal operation with well-behaved endpoints, capture packets on both interfaces to identify whether the firewall missed earlier handshake messages. Occasional drops may be benign if clients are retransmitting after legitimate timeouts. Contact Cisco TAC if drops prevent legitimate SCTP associations from establishing.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-cookie-echo-in-shut

SCTP association establishment attempt during graceful shutdown

This counter increments when the firewall receives an SCTP COOKIE-ECHO chunk while an existing SCTP association is in the process of graceful shutdown. The COOKIE-ECHO chunk is part of the SCTP four-way handshake used to establish new associations, but is invalid when the association is already shutting down (in SHUTDOWN-SENT, SHUTDOWN-RECEIVED, or SHUTDOWN-ACK-SENT state). The firewall drops these packets to enforce proper SCTP state machine behavior and prevent attempts to re-establish an association that is being torn down. This typically occurs in environments using SCTP inspection for telecom signaling protocols (such as Diameter, SIGTRAN) when endpoints attempt to re-initialize connections during or immediately after shutdown sequences, or when there is timing misalignment between peers during failover or restart scenarios.

Recommendation:

This drop is usually benign and indicates correct protocol enforcement. The SCTP endpoints should complete the shutdown sequence before attempting to establish a new association. If this counter increments frequently, investigate whether SCTP endpoints are experiencing rapid restart cycles, failover events, or configuration issues causing premature re-initialization attempts. Verify that SCTP inspection is configured correctly with 'inspect sctp' in the service policy. If the drops correlate with application connectivity issues, capture packets to determine whether endpoints are following proper SCTP shutdown procedures (SHUTDOWN → SHUTDOWN-ACK → SHUTDOWN-COMPLETE sequence). In most cases, the endpoints will retry the association establishment after the shutdown completes, and no action is required.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-cookie-echo-no-assoc

SCTP COOKIE-ECHO received without active association

The firewall received an SCTP COOKIE-ECHO chunk but has no matching association record in its connection table. This occurs when the association was already removed (due to timeout, explicit shutdown, or failover), when the COOKIE-ECHO is a stale retransmission from a previous connection attempt, or in asymmetric routing scenarios where the initial handshake (INIT and INIT-ACK) traversed a different path and the firewall did not observe the earlier negotiation. The COOKIE-ECHO is the third step in the four-way SCTP handshake and requires an existing association context created during the INIT exchange.

Recommendation:

This drop is typically benign and self-correcting. The SCTP client will detect the handshake failure and retry from the beginning (INIT). Investigate if the counter increments persistently: verify SCTP inspection is enabled and properly configured with 'show service-policy inspect sctp', check for asymmetric routing that prevents the firewall from seeing the complete handshake sequence, review association timeouts with 'show timeout sctp', and examine whether failover or clustering events are causing association state loss. In high-availability deployments, ensure SCTP association replication is functioning correctly. If the issue persists and prevents connection establishment, capture traffic on both interfaces to confirm the firewall is observing the full INIT/INIT-ACK exchange before the COOKIE-ECHO arrives.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-descriptor-unavailable

SCTP DATA chunk descriptor unavailable

This counter increments when the system cannot allocate memory for an internal tracking structure needed to process an incoming SCTP DATA chunk. The allocation failure occurs during DATA chunk processing when the chunk needs to be queued for out-of-order delivery, fragmentation reassembly, or stream reordering. This is a resource exhaustion condition that typically indicates the device is under memory pressure from high SCTP connection volume, large numbers of fragmented or out-of-order DATA chunks awaiting reassembly, or general system memory depletion. The affected DATA chunk is dropped, which will trigger retransmission by the SCTP peer.

Recommendation:

Check overall system memory usage with 'show memory' and 'show memory detail'. Review SCTP connection statistics with 'show conn protocol sctp' and 'show sctp' to identify if there are excessive associations or unusual traffic patterns. If memory is consistently low, investigate other memory consumers using 'show memory top-usage' and consider reducing connection limits, adjusting inspection policies, or upgrading to a platform with more memory. For transient spikes, the SCTP retransmission mechanism will recover automatically. If drops persist under normal load, contact Cisco TAC with output from 'show tech-support' and 'show asp drop' to investigate potential memory leaks or resource management issues.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-fwd-tsn-gap-out-of-range

SCTP FORWARD-TSN gap exceeds maximum

This counter increments when the firewall receives an SCTP FORWARD-TSN chunk (used in Partial Reliability SCTP) that attempts to advance the cumulative acknowledgment point by more than 100 transmission sequence numbers (TSNs) beyond the current position. The FORWARD-TSN mechanism allows SCTP endpoints to skip over unreliable or expired data without retransmitting it, but excessively large gaps may indicate a malformed packet, a misconfigured peer, or an attempt to manipulate the SCTP state machine. The firewall drops the packet to protect the integrity of the SCTP association. This drop typically occurs in carrier and telecom environments where SCTP is used for signaling protocols such as Diameter or M3UA (SS7-over-IP).

Recommendation:

Verify that both SCTP endpoints support Partial Reliability SCTP (PR-SCTP) and are configured consistently. Check for network conditions causing excessive packet loss or reordering that might lead to abnormally large TSN gaps. If the peer is legitimately attempting to skip a large amount of unreliable data, the gap limit of 100 TSNs may be insufficient for your deployment; contact Cisco TAC to discuss whether this is expected behavior for your signaling traffic patterns. If drops persist without corresponding application-layer issues, capture packets on both sides of the firewall to determine whether the FORWARD-TSN chunks are malformed or whether the peer is behaving incorrectly. In most cases, this drop indicates a protocol violation or misconfiguration rather than normal operation.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-fwd-tsn-in-invalid-state

SCTP FORWARD-TSN chunk received in invalid association state

The firewall dropped an SCTP packet containing a FORWARD-TSN chunk because the SCTP association was not in a valid state to process it. FORWARD-TSN chunks are part of the Partial Reliability SCTP (PR-SCTP) extension and are used to advance the cumulative acknowledgment point, allowing the sender to skip over unreliable data. These chunks are only valid when the association is in an established data-transfer state (ESTABLISHED, SHUTDOWN_RCVD, or SHUTDOWN_ACKSENT). This drop occurs when a FORWARD-TSN chunk arrives while the association is in CLOSED, COOKIE_WAIT, COOKIE_ECHOED, or SHUTDOWN_SENT state—typically during connection setup or after the local endpoint has initiated shutdown. Common causes include out-of-order or delayed packets arriving after an association has been torn down, clock skew or timing issues between endpoints, or protocol violations by misconfigured SCTP implementations. SCTP is primarily used in telecom and carrier environments for signaling protocols such as Diameter and M3UA.

Recommendation:

Check the SCTP association state using 'show sctp' to verify whether associations are completing the handshake properly or are being torn down prematurely. Review SCTP endpoint configurations to ensure both sides support PR-SCTP and are using compatible reliability policies. If drops occur during normal operation, investigate network latency or packet reordering that might cause FORWARD-TSN chunks to arrive after shutdown has been initiated. Enable 'debug sctp' to trace association state transitions and chunk processing timing. If the drops are infrequent and occur during connection teardown, they may be benign (delayed packets after shutdown). Persistent drops during active sessions indicate a protocol violation or incompatibility between SCTP implementations—verify that both endpoints correctly implement RFC 3758 (PR-SCTP). Contact Cisco TAC if drops correlate with application failures or if SCTP associations fail to establish.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-fwd-tsn-too-small

SCTP FORWARD-TSN chunk length is too small

The firewall received an SCTP packet containing a FORWARD-TSN chunk that is smaller than the minimum required size. The FORWARD-TSN chunk is part of the Partial Reliability SCTP (PR-SCTP) extension and is used to advance the cumulative acknowledgment point when unreliable messages are abandoned. Each FORWARD-TSN chunk must contain at least a chunk header and a new cumulative Transmission Sequence Number (TSN) field. This drop indicates the received chunk is malformed or truncated and cannot be safely processed. The packet is dropped to prevent potential memory access violations or protocol state corruption.

Recommendation:

This counter typically indicates malformed or corrupted SCTP traffic, possibly from a misconfigured peer, network corruption, or a security probe. Verify the SCTP endpoints are functioning correctly and that network devices between the peers are not corrupting packets. If the traffic is from a known legitimate source, capture the dropped packets and examine the SCTP chunk structure to identify whether the peer implementation is non-compliant. If drops persist from legitimate traffic, contact Cisco TAC with packet captures showing the malformed FORWARD-TSN chunks. This drop is a protective measure and should not occur during normal SCTP operation with compliant implementations.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-heartbeat-ack-no-assoc

SCTP heartbeat acknowledgment received without active association

The firewall received an SCTP HEARTBEAT-ACK chunk but could not find a corresponding SCTP association in its connection state table. SCTP uses heartbeat messages to monitor the reachability of alternate network paths in multi-homed configurations. The acknowledgment is a response to a heartbeat probe sent by the peer endpoint. This drop typically occurs when the association has already been torn down due to timeout, explicit shutdown, or resource limits, but the peer continues to send heartbeat acknowledgments for paths it believes are still active. It may also occur during high-availability failover transitions when association state has not yet synchronized to the standby unit, or when network address translation interferes with association lookup. In environments with frequent association churn or aggressive heartbeat intervals, occasional increments of this counter are expected and do not indicate a problem.

Recommendation:

Review the rate of these drops relative to total SCTP traffic. Occasional drops are normal when associations terminate while heartbeat timers are still active on the peer. Sustained or high drop rates may indicate: (1) association timeout mismatches between peers—verify both endpoints use compatible heartbeat and association timeout values; (2) firewall resource exhaustion causing premature association cleanup—check memory and connection limits with 'show resource usage' and 'show conn count'; (3) high-availability synchronization delays—verify the state link is operational and not congested; (4) network address translation issues affecting association tracking—review NAT configuration for SCTP flows. Use 'show sctp' to view active associations and 'show service-policy inspect sctp' to monitor inspection statistics. If drops correlate with application failures, capture packets to determine whether associations are being removed prematurely or heartbeat timers are misconfigured.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-heartbeat-no-assoc

SCTP HEARTBEAT received without active association

The firewall received an SCTP HEARTBEAT chunk but could not match it to any active SCTP association in its connection table. SCTP endpoints send HEARTBEAT chunks periodically to verify that network paths remain reachable. This drop occurs when a heartbeat arrives after the firewall has already torn down the association (due to timeout, explicit shutdown, or failover), when the association was never established, or in cluster deployments when the heartbeat arrives at a unit that does not own the connection. This is typically a transient condition during normal SCTP session lifecycle events.

Recommendation:

This counter incrementing occasionally is normal and expected during SCTP session teardown or network topology changes. Investigate if you see sustained or high-volume drops: verify that SCTP associations are completing the four-way handshake (INIT/INIT-ACK/COOKIE-ECHO/COOKIE-ACK) successfully, check for asymmetric routing that might cause heartbeats to arrive at the wrong cluster member, confirm that SCTP timeout values are appropriate for your network latency, and review firewall connection table capacity. In cluster deployments, ensure director localization is functioning correctly. If SCTP traffic is failing, consider enabling SCTP state-bypass mode to reduce stateful tracking overhead.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-init-0-stream-cnt

SCTP INIT chunk contains zero stream count

This counter increments when the firewall receives an SCTP INIT chunk (used to establish a new association) that specifies zero for either the Number of Inbound Streams or Number of Outbound Streams parameter. Both values are mandatory fields in the INIT chunk and must be at least 1 according to the SCTP protocol specification (RFC 4960 / RFC 9260). A zero value indicates either a malformed packet, a protocol implementation error on the sending endpoint, or potentially a malicious attempt to trigger undefined behavior. The firewall rejects the association attempt, drops the packet, and may send an ABORT chunk with an 'Invalid Mandatory Parameter' error back to the sender. This is a protocol validation failure during the SCTP four-way handshake, before any association state is created.

Recommendation:

This drop typically indicates a problem with the SCTP client or server implementation sending the INIT chunk. Verify that the SCTP endpoint software is correctly configured and up to date. If the traffic is legitimate, capture the dropped packets to confirm whether the stream count fields are actually zero or if there is a parsing issue. Check for: (1) misconfigured SCTP applications that may be setting stream parameters incorrectly, (2) corrupted packets due to network issues, or (3) potential attack traffic attempting to exploit SCTP stack vulnerabilities. If the source is a known legitimate SCTP endpoint (such as Diameter, SIGTRAN/M3UA, or WebRTC signaling), contact the application vendor. Persistent drops from unknown sources may indicate scanning or attack activity and can generally be ignored as the firewall is correctly enforcing protocol compliance.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-init-0-tag

SCTP INIT chunk contains zero initiate tag

The firewall received an SCTP INIT chunk with an initiate tag field set to zero, which violates the SCTP protocol specification. The initiate tag is a mandatory 32-bit value used to validate subsequent packets in an SCTP association and must be non-zero. This counter increments when SCTP inspection detects this protocol violation during the initial handshake. The firewall drops the packet and sends an ABORT message with an 'Invalid Parameter' error cause back to the sender. This typically indicates a misconfigured or non-compliant SCTP endpoint, corrupted packets in transit, or potentially malicious traffic attempting to exploit protocol weaknesses. The drop occurs before any association state is created, protecting the firewall from invalid connection attempts.

Recommendation:

This drop indicates a protocol violation by the remote SCTP endpoint. Verify that the SCTP client or server initiating the connection is properly configured and running compliant SCTP stack software. Check for network issues that might corrupt packets in transit, such as faulty hardware or middleboxes that incorrectly modify SCTP headers. If the traffic is legitimate, update or patch the SCTP application to ensure RFC 4960 compliance. If drops persist from specific sources, investigate whether the traffic is malicious or part of a scanning attempt. Review SCTP inspection policy maps if custom policies are configured. This drop is expected behavior for malformed traffic and does not indicate a firewall problem.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-init-ack-0-stream-cnt

SCTP INIT-ACK rejected due to zero stream count

The firewall received an SCTP INIT-ACK message during association establishment with either the inbound stream count or outbound stream count set to zero. SCTP associations require at least one stream in each direction to carry data. When this counter increments, the firewall drops the INIT-ACK and sends an ABORT message back to the peer with an 'Invalid Mandatory Parameter' error. This prevents the association from being established. This validation enforces RFC 4960 requirements and protects against malformed or malicious SCTP traffic that could cause resource exhaustion or protocol violations. The counter typically indicates a misconfigured SCTP endpoint, a software bug in the peer's SCTP stack, or an attack attempt. SCTP is commonly used in telecom and mobile network signaling environments (Diameter, SS7/M3UA) where proper stream negotiation is critical for multi-stream operation.

Recommendation:

Verify the SCTP endpoint configuration on the peer that sent the INIT-ACK. Check that the peer's SCTP implementation is correctly configured to negotiate at least one inbound and one outbound stream. If the peer is a known legitimate device, investigate whether it is running outdated or buggy SCTP stack software. Capture packets to confirm the stream count values in the INIT-ACK chunk. If the traffic is from an unknown or untrusted source, this may indicate a reconnaissance or denial-of-service attempt and can be safely ignored. For legitimate traffic, coordinate with the application or device vendor to correct the SCTP stack configuration or upgrade to a compliant version. This drop is expected behavior and protects the firewall from establishing invalid associations.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-init-ack-inv-ipv4-param-len

SCTP INIT-ACK chunk contains IPv4 address parameter with incorrect length

This counter increments when the firewall receives an SCTP INIT-ACK chunk during association establishment that contains an IPv4 address parameter with an invalid length field. SCTP endpoints use INIT-ACK messages to respond to connection requests and may include multiple IPv4 addresses to support multihoming (redundant network paths). Each IPv4 address parameter must be exactly 8 bytes: a 4-byte parameter header followed by a 4-byte IPv4 address. The firewall drops packets that violate this requirement to prevent processing of malformed or potentially malicious traffic. This drop typically indicates either a misbehaving SCTP implementation on the remote peer, packet corruption in transit, or an attempted exploit targeting SCTP protocol parsing.

Recommendation:

Verify that all SCTP endpoints in your environment are using compliant SCTP implementations. Check for firmware or software updates on devices generating INIT-ACK messages. If drops occur consistently from specific peers, capture the traffic and examine the INIT-ACK chunk structure to identify whether the peer is advertising IPv4 addresses incorrectly. Occasional drops may indicate network corruption or scanning activity and can typically be ignored if SCTP associations are establishing successfully. If legitimate SCTP traffic is being blocked, contact Cisco TAC with packet captures showing the malformed INIT-ACK messages.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-init-ack-inv-ipv6-param-len

SCTP INIT-ACK contains invalid IPv6 parameter length

The firewall dropped an SCTP INIT-ACK packet because an IPv6 address parameter within the chunk has an incorrect length field. During SCTP association establishment, the INIT-ACK message can include optional IPv6 address parameters to advertise additional addresses for multihoming (allowing an endpoint to be reachable via multiple IP addresses for redundancy). Each IPv6 address parameter must be exactly 20 bytes (4-byte parameter header plus 16-byte IPv6 address). This counter increments when the firewall detects a length mismatch, indicating either a malformed packet from a non-compliant SCTP implementation, packet corruption in transit, or a potential attack attempting to exploit parsing vulnerabilities. The firewall rejects the malformed INIT-ACK to prevent association establishment with invalid parameters.

Recommendation:

This drop typically indicates a problem with the SCTP peer sending the INIT-ACK response. Verify that both SCTP endpoints are using compliant implementations that follow RFC 4960 parameter encoding rules. If the drops are persistent from a specific peer, check whether that system's SCTP stack has known issues or requires updates. Capture the dropped packets to examine the actual parameter length values in the INIT-ACK chunk—the IPv6 address parameter type is 6, and the length field should always be 20 bytes. If drops occur sporadically, investigate potential network issues causing packet corruption. Consistent drops from multiple peers may indicate an intermediary device (middlebox, load balancer) incorrectly modifying SCTP packets. This drop is a security and protocol compliance measure; the firewall is correctly rejecting invalid traffic. Contact Cisco TAC if legitimate SCTP traffic from known-good implementations is being dropped.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-init-asconf-auth-inconsistent

SCTP INIT advertises dynamic address reconfiguration without authentication support

This counter increments when the firewall receives an SCTP INIT chunk that advertises support for ASCONF (dynamic address reconfiguration) but does not advertise support for AUTH (authentication). RFC 5061 requires that any SCTP endpoint advertising ASCONF capability must also support authentication to prevent address hijacking attacks. The firewall drops these packets to enforce protocol compliance and protect against malicious address reconfiguration attempts. This drop typically indicates a misconfigured SCTP endpoint, a non-compliant SCTP stack, or an attempted attack. ASCONF allows SCTP endpoints to dynamically add or remove IP addresses from an established association (used in multihomed deployments), but without authentication, an attacker could inject malicious address changes.

Recommendation:

Verify that both SCTP endpoints are configured to support authentication (SCTP-AUTH) when using dynamic address reconfiguration (ASCONF). Check the SCTP stack configuration on the initiating endpoint to ensure AUTH is enabled alongside ASCONF. If the endpoint legitimately does not support authentication, disable ASCONF capability in the SCTP stack configuration. If drops persist from known-good endpoints, verify that the SCTP implementation is RFC 5061 compliant and that INIT chunks include the Supported Extensions parameter listing both ASCONF and AUTH chunk types. This is a security enforcement drop and is working as designed—do not attempt to bypass it. Contact the SCTP application vendor if their stack does not properly advertise AUTH support when ASCONF is enabled.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-init-in-shutdown

SCTP INIT chunk received during graceful shutdown

This counter increments when the firewall receives an SCTP INIT chunk (association establishment request) while an existing SCTP association is in the final stage of graceful shutdown. Specifically, this occurs when the association is in the SHUTDOWN-ACK-SENT state—after the firewall has sent a SHUTDOWN-ACK and is waiting for the peer to send a SHUTDOWN-COMPLETE to finalize termination. According to RFC 4960, receiving an INIT chunk at this point represents a restart collision: one endpoint is trying to establish a new association while the other is still completing shutdown of the previous association. The firewall drops the INIT chunk, sends an error response to the peer, and retransmits the SHUTDOWN-ACK to continue the graceful shutdown sequence. This behavior prevents ambiguous association state and ensures clean termination before any new association can be established.

Recommendation:

This drop is typically benign and indicates normal protocol behavior when SCTP endpoints have timing mismatches during association restart—for example, when one peer initiates a new connection attempt before the other has fully completed shutdown of the previous association. No action is required if this counter increments occasionally. However, if you observe a high or sustained rate of these drops for a specific SCTP association, investigate the following: (1) Check whether the SCTP application or endpoints are configured with very short reconnection timers that cause restart attempts before graceful shutdown completes. (2) Verify that both SCTP peers are properly handling shutdown sequences and not prematurely attempting to re-establish associations. (3) Review SCTP timeout settings on both endpoints to ensure adequate time for graceful shutdown completion (typically several seconds). If the issue persists and affects application connectivity, capture packet traces on both sides of the firewall to determine whether one endpoint is failing to complete the shutdown handshake or is aggressively retrying connection establishment.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-init-inv-ipv4-param-len

SCTP INIT chunk contains IPv4 address parameter with incorrect length

The firewall received an SCTP INIT chunk containing an IPv4 address parameter with an invalid length field. According to RFC 4960, IPv4 address parameters in SCTP INIT chunks must be exactly 8 bytes (4-byte parameter header plus 4-byte IPv4 address). This counter increments when the length field in the parameter does not match this expected value. This typically indicates a malformed packet from a non-compliant SCTP implementation, packet corruption in transit, or a potential attack attempting to exploit SCTP parsing vulnerabilities. The firewall drops the packet and sends an ABORT chunk with an 'Invalid Parameter' error to the sender. The SCTP association will not be established.

Recommendation:

This drop usually indicates a problem with the SCTP client or server implementation. Verify that both endpoints are using RFC 4960-compliant SCTP stacks. If the traffic is legitimate, capture packets on both sides of the firewall to determine whether corruption is occurring in transit or if one endpoint is sending malformed INIT chunks. Check for any middleboxes between the endpoints that might be modifying SCTP packets incorrectly. If the drops are frequent and from untrusted sources, they may represent scanning or attack traffic and can be safely ignored. For multihomed SCTP endpoints, ensure that all advertised IP addresses are correctly formatted in the INIT chunk parameters. If the issue persists with known-good SCTP implementations, contact Cisco TAC with packet captures showing the malformed INIT chunk.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-init-inv-ipv6-param-len

SCTP INIT chunk contains invalid IPv6 address parameter length

The firewall dropped an SCTP INIT chunk because an IPv6 address parameter within the chunk specified an incorrect length value. SCTP INIT chunks can contain optional IPv6 address parameters to advertise multihomed endpoints (multiple IP addresses for the same association). Each IPv6 address parameter must be exactly 20 bytes: a 4-byte parameter header plus a 16-byte IPv6 address. This counter increments when the length field in an IPv6 address parameter does not match the expected 20-byte size, indicating either a malformed packet, a corrupted transmission, or a non-compliant SCTP implementation. The firewall enforces strict RFC 4960 compliance during SCTP association establishment to prevent potential parsing vulnerabilities and ensure protocol correctness.

Recommendation:

This drop typically indicates a problem with the SCTP client or server implementation, or packet corruption in transit. Capture the dropped packets to examine the SCTP INIT chunk structure and verify the IPv6 address parameter length fields. If the peer is using a custom or legacy SCTP stack, check for known bugs or updates. If drops occur consistently from specific endpoints, investigate whether those systems have SCTP stack issues or are behind middleboxes that may be corrupting SCTP packets. This is a legitimate security validation—do not disable SCTP inspection to work around this drop. If you believe the firewall is incorrectly rejecting valid SCTP traffic, collect packet captures showing the full SCTP handshake and contact Cisco TAC for analysis.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-init-inv-param-len

SCTP INIT ACK contains invalid parameter length value

This counter is incremented and the packet is dropped when SCTP INIT ACK chunk contains invalid parameter length value.

Recommendation:

None

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-init-new-addr

SCTP restart attempt with unauthorized address

The firewall dropped an SCTP restart attempt because the peer included a new IP address that was not part of the original association. When an SCTP association is already established or in the process of being established, the firewall validates that any restart attempt uses only the addresses that were originally negotiated during association setup. This security check prevents an attacker from hijacking an existing SCTP association by injecting a restart message with their own address. The drop occurs when the firewall receives an SCTP INIT chunk for an existing association that contains an address parameter not present in the original address list. This is most commonly seen in SCTP multihoming deployments where endpoints have multiple IP addresses, particularly in carrier and telecom environments using Diameter or SS7 signaling protocols.

Recommendation:

This drop is a security protection and typically indicates either a misconfiguration or a potential attack. First, verify that both SCTP endpoints are configured with consistent address lists—if an endpoint legitimately needs to add or change addresses after association establishment, it should use the SCTP ASCONF (Address Configuration) extension rather than restarting with a new INIT. Check that the SCTP application is not incorrectly attempting to restart associations with different interface addresses due to routing or failover events. If the drop occurs during legitimate failover or network topology changes, ensure the SCTP endpoints support and use dynamic address reconfiguration (ASCONF) rather than full association restart. If drops persist during normal operation, capture packet traces to determine whether the restart attempts are legitimate or malicious. Contact Cisco TAC if you observe this drop during expected SCTP multihoming behavior with properly configured endpoints.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-init-param-too-small

SCTP INIT or INIT-ACK chunk contains parameter with invalid length field

The firewall received an SCTP INIT or INIT-ACK chunk containing an optional parameter with a malformed length field. SCTP parameters use a Type-Length-Value (TLV) encoding where each parameter begins with a 4-byte header (2 bytes for type, 2 bytes for length). The length field must include at least the header itself (minimum value of 4). This packet advertised a parameter length smaller than the header size, violating the SCTP protocol specification (RFC 4960). Such malformed packets typically indicate either corrupted traffic, a misbehaving SCTP stack, or a deliberate attack attempting to trigger parsing vulnerabilities. The firewall drops these packets during association establishment to prevent potential buffer underflows or out-of-bounds memory access.

Recommendation:

This drop protects against malformed or malicious SCTP traffic and is expected behavior. Investigate the source of the traffic: if the packets originate from a legitimate SCTP endpoint (such as Diameter or SS7/M3UA signaling nodes), the remote system may have a software defect or corrupted SCTP implementation that requires patching. If the traffic appears to be from an unknown or untrusted source, it may represent an attack or scanning activity. Capture packets using 'capture' commands to examine the malformed INIT or INIT-ACK chunk structure. No configuration change is needed on the firewall—this validation cannot be disabled and should not be bypassed. Contact the vendor of the SCTP endpoint if legitimate traffic is being dropped.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-init-redundancy-auth-inconsistent

SCTP INIT advertises REDUNDANCY extension without required AUTH extension

The firewall received an SCTP INIT chunk that advertises support for the REDUNDANCY extension but does not advertise support for the AUTH (authentication) extension. According to SCTP protocol specifications, the REDUNDANCY extension requires the AUTH extension to be present for secure operation. When this inconsistency is detected during association establishment, the firewall drops the packet to prevent a potentially insecure or malformed SCTP association from being created. This typically indicates a misconfigured or non-compliant SCTP endpoint attempting to establish a connection.

Recommendation:

Verify the SCTP endpoint configuration on the remote peer. The peer must advertise both REDUNDANCY and AUTH extensions together in the INIT chunk, or neither. If the remote endpoint is a third-party SCTP implementation, check for firmware updates or configuration options that control SCTP extension negotiation. If the peer is intentionally configured to use REDUNDANCY, ensure AUTH is also enabled. If this drop occurs frequently from a known legitimate peer, contact the vendor of that SCTP implementation to resolve the protocol compliance issue. This is not a firewall misconfiguration—the drop is enforcing correct SCTP protocol behavior.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-init-restart-bad-ip

SCTP restart attempt with unauthorized address

The firewall dropped an SCTP restart attempt because the new connection request contained an address that was not present in the original connection setup. When an SCTP association already exists and a new initialization request arrives (a restart scenario), the firewall validates that the peer is not attempting to add new addresses to the association. This security check prevents an attacker from hijacking an existing SCTP association by injecting unauthorized addresses into a restart request. This drop occurs when SCTP multihoming is in use and a peer attempts to restart the association with a different set of addresses than originally negotiated.

Recommendation:

This drop indicates a potential security issue or misconfiguration. Verify that the SCTP peer is configured with consistent address lists across restarts. If the peer legitimately needs to change its address set, the existing association should be properly torn down before establishing a new one with different addresses. If this drop occurs frequently, investigate whether the SCTP peer has unstable addressing or whether an attacker is attempting to manipulate the association. For legitimate address changes in multihomed SCTP deployments, use the SCTP dynamic address reconfiguration extension (ASCONF) rather than restarting with different addresses.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-init-rwnd-too-small

SCTP INIT or INIT-ACK receive window below minimum threshold

The firewall dropped an SCTP association setup packet (INIT or INIT-ACK chunk) because the advertised receive window was smaller than the minimum required value of 1500 bytes. The receive window field in these handshake messages tells the peer how much data it can accept before requiring acknowledgment. A value below 1500 bytes is considered too small to support reliable SCTP communication and may indicate a misconfigured or non-compliant SCTP endpoint. This validation protects against endpoints that cannot buffer at least one maximum-sized Ethernet frame, which would cause fragmentation issues and poor performance. The firewall sends an ABORT chunk with an 'Invalid Mandatory Parameter' error back to the sender when this occurs.

Recommendation:

This drop typically indicates a problem with the SCTP endpoint configuration. Check the SCTP stack settings on the client or server that sent the rejected INIT or INIT-ACK message—the receive buffer size may be configured too small. Most SCTP implementations default to much larger receive windows (often 64 KB or more), so values below 1500 bytes usually point to explicit misconfiguration or a non-standard implementation. If you are seeing this counter increment, capture packets on both sides of the firewall to identify which endpoint is advertising the undersized window. For carrier-grade deployments using Diameter or M3UA signaling over SCTP, verify that the signaling equipment meets the minimum buffer requirements. If the endpoint cannot be reconfigured and the traffic is trusted, contact Cisco TAC to discuss whether SCTP state-bypass mode is appropriate for your deployment—though this disables stateful inspection and should only be used when necessary.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-init-too-small

SCTP INIT chunk length field is smaller than minimum required size

The firewall dropped an SCTP packet because the length field in the INIT chunk header indicates a size smaller than the minimum required for a valid INIT chunk. SCTP INIT chunks are used to establish new associations and must contain mandatory parameters including the initiate tag, receive window, and stream counts. When the declared chunk length is too small to accommodate these required fields, the packet is rejected as malformed. This validation protects against crafted or corrupted packets that could cause processing errors. This drop typically occurs during SCTP association establishment and affects signaling protocols that use SCTP transport, such as Diameter (mobile network authentication), M3UA (SS7-over-IP signaling), and other telecom applications. The drop may indicate network corruption, a misconfigured SCTP endpoint, or a potential attack using malformed packets.

Recommendation:

This drop indicates malformed SCTP traffic and is typically a protective measure. Verify the SCTP client or server implementation is RFC 4960 compliant and not sending truncated or corrupted INIT chunks. If the traffic is legitimate, capture packets on both sides of the firewall to determine where the corruption occurs—this may indicate a network issue such as MTU problems or intermediate device interference. If drops are frequent and from untrusted sources, this may represent reconnaissance or attack traffic and can be safely ignored. For telecom signaling applications (Diameter, M3UA), coordinate with the network equipment vendor to ensure proper SCTP stack configuration. If SCTP inspection is enabled, verify that the inspection policy is not interfering with legitimate traffic patterns.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-initack-0-tag

SCTP INIT-ACK chunk contains zero initiate tag

The firewall dropped an SCTP INIT-ACK chunk because the initiate tag field was set to zero. The initiate tag is a mandatory parameter in the SCTP association establishment handshake that must contain a non-zero value. This tag becomes the verification tag used to validate all subsequent packets in the association. A zero value indicates either a malformed packet, a non-compliant SCTP implementation, or potential attack traffic attempting to disrupt SCTP associations. The firewall enforces RFC 4960 compliance by rejecting INIT-ACK chunks with invalid initiate tags during the four-way handshake (INIT, INIT-ACK, COOKIE-ECHO, COOKIE-ACK). This drop occurs during SCTP inspection when the firewall is acting as a middlebox validating signaling traffic, commonly seen in carrier and telecom environments running protocols like Diameter or M3UA over SCTP.

Recommendation:

This counter typically indicates malformed or malicious SCTP traffic. Verify the SCTP peer implementation is RFC 4960 compliant and correctly populating the initiate tag field in INIT-ACK chunks. If the traffic is legitimate, contact the vendor of the SCTP endpoint generating the INIT-ACK responses. Capture packets on both sides of the firewall to confirm whether the zero tag originates from the peer or is the result of packet corruption in transit. If this counter increments frequently from a specific peer, that endpoint may have a software defect or be under attack. For troubleshooting, enable SCTP debug tracing and review the SCTP association state. This drop is expected behavior for protocol validation and protects against malformed signaling traffic that could destabilize SCTP associations.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-initack-no-matching-init

SCTP INIT-ACK received without matching INIT

The firewall received an SCTP INIT-ACK chunk but could not find the corresponding INIT chunk state that should have been created earlier in the four-way handshake. During SCTP association establishment, the firewall tracks the initial INIT message and creates internal state (a cookie) to validate the subsequent INIT-ACK response. This drop occurs when that state is missing—either because it was never created (the INIT traversed a different path or firewall), or because it has already timed out or been removed. Common scenarios include asymmetric routing where the INIT and INIT-ACK traverse different firewalls in a cluster or redundant topology, network congestion or delays causing the INIT-ACK to arrive after the connection state has expired, or SCTP multihoming configurations where client and server use multiple redundant network paths.

Recommendation:

If this counter increments occasionally, it typically indicates normal timing variations or asymmetric routing in your network topology and may not require action. If the counter increments frequently or correlates with SCTP connection failures, investigate the following: verify that both directions of SCTP traffic traverse the same firewall (check routing tables and use packet captures to confirm symmetry); for clustered deployments, ensure SCTP flows are properly distributed or consider enabling connection replication; review SCTP idle timeout settings (configurable via the timeout command) to ensure they accommodate your network's round-trip times and potential delays; examine network paths for congestion or packet loss that might delay INIT-ACK delivery beyond the connection timeout window. Use packet capture to confirm whether INIT messages are reaching the firewall before their corresponding INIT-ACK responses. In multihomed SCTP deployments, verify that all paths are properly inspected and that inspection is consistently applied across redundant interfaces.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-initack-rwnd-too-small

SCTP INIT-ACK advertised receive window below minimum threshold

The firewall dropped an SCTP INIT-ACK chunk because the advertised receive window value was less than 1500 bytes. During SCTP association establishment, the responding peer advertises its receive buffer size in the INIT-ACK chunk; this value must be at least 1500 bytes to ensure the peer can accept a full-sized packet. When the firewall detects a receive window below this threshold, it drops the INIT-ACK and sends an ABORT with an invalid parameter error to prevent the association from establishing with insufficient buffer capacity. This typically indicates a misconfigured or non-compliant SCTP endpoint. In versions prior to 9.6.2 and 9.7.1, this counter could increment incorrectly when legitimate large window values (such as 65536) were misinterpreted as zero due to an internal data type issue; this has been resolved in later releases.

Recommendation:

Verify that both SCTP endpoints are configured with adequate receive buffer sizes (at least 1500 bytes, typically much larger for production traffic). If this counter increments on software versions earlier than 9.6.2 or 9.7.1, upgrade to a fixed release, as the drops may be false positives caused by a known defect. Use 'debug sctp' to capture the actual receive window value advertised in the INIT-ACK chunk. If the peer is legitimately advertising a window below 1500 bytes, the peer's SCTP stack configuration must be corrected. This is a protocol compliance check and cannot be disabled.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-initack-too-small

SCTP INIT-ACK chunk length field is smaller than minimum required size

This counter increments when the firewall receives an SCTP INIT-ACK chunk during association establishment, but the chunk's length field indicates a size smaller than the minimum required for a valid INIT-ACK. The INIT-ACK chunk must contain a chunk header plus initialization parameters (verification tag, receiver window, stream counts, and optional parameters). When the declared length is too small to accommodate these mandatory fields, the packet is dropped to prevent processing of malformed or truncated data. This typically occurs due to packet corruption in transit, misconfigured or buggy SCTP implementations, or malicious traffic attempting to exploit protocol parsing. SCTP inspection must be enabled for this validation to occur.

Recommendation:

This drop indicates malformed SCTP traffic and is a protective measure. Investigate the source of the INIT-ACK packets to determine whether the issue stems from a legitimate endpoint with implementation problems or from malicious traffic. Check for patterns in the source addresses using 'show asp drop' to identify if drops are concentrated from specific hosts. If the traffic is from a known SCTP application (such as Diameter signaling, SS7-over-IP, or mobile network infrastructure), verify that the application software is up to date and properly configured. Capture packets using 'capture' commands to examine the actual INIT-ACK chunk structure and length field. If drops persist from legitimate endpoints, contact the vendor of the SCTP application. If drops appear to be from scanning or attack traffic, consider applying access control lists to block the source. This drop is expected and benign when protecting against malformed traffic.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-inva-ver-tag

SCTP packet dropped due to verification tag mismatch

This counter increments when an SCTP packet is received with a verification tag that does not match the expected tag for the association. The verification tag is a 32-bit value in the SCTP common header used to validate that packets belong to the correct association and protect against blind attacks and stale packets. A mismatch typically occurs when: (1) the packet belongs to an old association that has been terminated but the peer has not yet learned of the termination, (2) the packet is out-of-the-blue (OOTB) and does not correspond to any active association, (3) the packet has been corrupted in transit, or (4) the packet is part of a spoofing or replay attack. This validation is a fundamental SCTP protocol requirement defined in RFC 4960.

Recommendation:

This drop is usually benign and indicates normal protocol operation when cleaning up stale associations or rejecting invalid traffic. If the counter is incrementing steadily, investigate: (1) Check for asymmetric routing or middlebox interference that might be causing packets from different association phases to arrive out of order. (2) Verify that both SCTP endpoints are properly synchronized and not experiencing frequent restarts or failovers that could cause association state mismatches. (3) Use packet captures to examine the verification tags in dropped packets and compare them against active associations visible in 'show sctp' output. (4) If the drops correlate with application failures, check whether the SCTP application is properly handling association lifecycle events (INIT, SHUTDOWN, ABORT). (5) In multihomed SCTP deployments, ensure all paths are functioning correctly and not delivering packets from terminated associations. Contact Cisco TAC if drops persist and correlate with service disruption.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-invalid-bundle

SCTP packet contains INIT, INIT-ACK, or SHUTDOWN-COMPLETE bundled with other chunks

The firewall dropped an SCTP packet because it contained an INIT, INIT-ACK, or SHUTDOWN-COMPLETE chunk bundled together with other chunks in the same packet. According to RFC 4960, these three control chunks must always appear alone in an SCTP packet and cannot be bundled with any other chunks. This counter indicates a protocol violation, typically caused by a misconfigured or non-compliant SCTP endpoint, or potentially malicious traffic attempting to exploit SCTP state machine vulnerabilities. The firewall enforces this requirement during SCTP stateful inspection to ensure proper association establishment and teardown.

Recommendation:

This drop usually indicates a problem with the SCTP endpoint implementation or malicious traffic. Verify that both SCTP endpoints are RFC 4960 compliant and running current software versions. If the traffic is legitimate, contact the vendor of the SCTP application (such as Diameter or M3UA signaling equipment) to report the protocol violation. Capture the dropped packets to confirm the bundling violation. If you see this counter incrementing continuously, investigate whether the source is attempting to exploit SCTP vulnerabilities. This is a legitimate protocol enforcement and should not be bypassed.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-param-supaddrlen-inv

SCTP INIT or INIT-ACK chunk contains malformed Supported Address Types parameter

This counter increments when the firewall receives an SCTP INIT or INIT-ACK chunk during association establishment that contains a Supported Address Types parameter with an invalid length field. The parameter length must be at least 4 bytes to accommodate the standard parameter header structure defined in RFC 4960. When this validation fails, the packet is dropped and the SCTP association cannot be established.

This drop typically indicates one of the following:

• A malformed or corrupted SCTP packet from a misconfigured or buggy SCTP endpoint
• An attempted protocol attack using crafted SCTP packets with invalid parameter encoding
• Network corruption affecting the SCTP parameter length field during transit

The firewall performs strict RFC 4960 compliance checking on SCTP control chunks to prevent protocol-level attacks and ensure only well-formed associations are permitted. This validation occurs during the initial four-way handshake before any SCTP association state is created.

Recommendation:

1. Identify the source of the malformed SCTP traffic using packet captures or connection logs to determine which endpoint is sending invalid INIT or INIT-ACK messages.

2. If the traffic originates from a known SCTP application (such as Diameter or M3UA signaling), verify the application software version and check for known bugs or misconfigurations in the SCTP stack implementation.

3. Check for network devices between the endpoints that might be corrupting SCTP packets, particularly middleboxes or load balancers that attempt to inspect or modify SCTP traffic.

4. If the drops are infrequent and isolated, they may represent scanning or attack traffic and can be safely ignored.

5. If legitimate SCTP associations are failing to establish and this counter is incrementing, capture the failing INIT/INIT-ACK exchange and examine the Supported Address Types parameter structure to identify the specific encoding error.

6. Contact Cisco TAC if legitimate SCTP traffic from a known-good endpoint is being dropped, providing packet captures showing the malformed parameter.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-sack-in-invalid-state

SCTP SACK chunk received during association setup

The firewall received an SCTP Selective Acknowledgment (SACK) chunk while the association was still being established. SACK chunks are used to acknowledge received DATA chunks, but they are only valid after the four-way handshake completes and the association reaches the ESTABLISHED state. This counter increments when a SACK arrives while the association is in CLOSED, COOKIE-WAIT, or COOKIE-ECHOED state—before the handshake sequence (INIT, INIT-ACK, COOKIE-ECHO, COOKIE-ACK) has finished. The remote peer is violating the SCTP protocol by sending acknowledgments before any data transfer should occur. The firewall removes the invalid SACK chunk from the packet; if the SACK was the only chunk, the entire packet is dropped.

Recommendation:

This typically indicates a misbehaving SCTP peer or an out-of-order packet replay. Verify that both SCTP endpoints are RFC-compliant implementations. Check for network conditions causing severe packet reordering or duplication that might deliver a SACK from a previous association attempt. If the counter increments persistently and associations fail to establish, capture traffic on both sides of the firewall to identify which peer is sending premature SACK chunks. In most cases, these drops are benign—the firewall is correctly enforcing the SCTP state machine, and the association will complete normally once the handshake finishes. Contact Cisco TAC if associations consistently fail to establish and this counter correlates with the failures.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-sack-no-assoc

SCTP selective acknowledgment received after association removed

The firewall received an SCTP selective acknowledgment (SACK) chunk for a connection that no longer has an active association in the firewall's state table. SCTP associations are removed when the connection is explicitly closed (SHUTDOWN or ABORT), when the idle timeout expires, or during failover and cluster topology changes. This drop typically occurs when a SACK arrives after the firewall has already torn down the association due to one of these events. It can also occur in asymmetric routing scenarios where the SACK takes a different path than the original data flow, or when packets are delayed or reordered in the network. In multi-homed SCTP deployments with equal-cost multi-path (ECMP) routing, response packets may arrive on different interfaces than expected, causing the firewall to be unable to correlate the SACK with an existing association.

Recommendation:

This counter incrementing is typically benign and indicates normal timing variations in connection teardown or network reordering. If the counter is increasing steadily, verify that SCTP idle timeouts are appropriately configured for your application using the 'timeout sctp' command - the default may be too short for applications with long idle periods between data transmissions. Check for asymmetric routing by ensuring SCTP response packets return through the same firewall interface where the original packets exited. In clustered or high-availability deployments, verify that SCTP associations are properly synchronized between units. If the drops correlate with connection failures, capture traffic on both sides of the firewall to determine whether SACKs are arriving significantly delayed or whether the association is being prematurely removed. For multi-homed SCTP deployments with ECMP, configure static routes or policy-based routing to ensure response packets return via the same interface.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-sack-too-small

SCTP SACK chunk length below minimum

The firewall received an SCTP packet containing a Selective Acknowledgment (SACK) chunk whose length field is smaller than the minimum required by the SCTP protocol specification. A valid SACK chunk must contain at least 16 bytes: a 4-byte chunk header plus a 12-byte SACK body (cumulative TSN acknowledgment, advertised receiver window, gap acknowledgment block count, and duplicate TSN count). This counter increments when SCTP inspection detects a SACK chunk that does not meet this minimum size requirement. The packet is dropped to protect the firewall from processing malformed or potentially malicious SCTP traffic. This validation occurs when SCTP inspection is enabled and applies to all SCTP associations passing through the firewall.

Recommendation:

This drop typically indicates malformed SCTP traffic, which may result from a misbehaving SCTP endpoint, network corruption, or a malicious attempt to exploit protocol parsing. Verify that all SCTP endpoints in your environment are using compliant SCTP implementations. If drops occur consistently from specific endpoints, investigate those systems for software bugs or misconfigurations. Capture and analyze the dropped packets to determine whether the malformation is consistent or intermittent. If the traffic is legitimate but non-compliant, contact the vendor of the SCTP application. Persistent drops from unknown sources may indicate reconnaissance or attack activity and should be investigated from a security perspective. This drop is expected and protective behavior—do not disable SCTP inspection to work around it.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-shutdown-ack-in-invalid-state

SCTP SHUTDOWN-ACK received outside graceful shutdown sequence

This counter increments when the firewall receives an SCTP SHUTDOWN-ACK chunk, but the association is not in a valid shutdown state. During normal SCTP graceful termination, SHUTDOWN-ACK is the second message in a three-way handshake (SHUTDOWN → SHUTDOWN-ACK → SHUTDOWN-COMPLETE). The firewall only accepts SHUTDOWN-ACK when the association is in SHUTDOWN-SENT (waiting for acknowledgment after sending SHUTDOWN), SHUTDOWN-RCVD (received SHUTDOWN from peer), or SHUTDOWN-ACKSENT (already sent SHUTDOWN-ACK). If SHUTDOWN-ACK arrives in any other state—such as ESTABLISHED, CLOSED, COOKIE-WAIT, or COOKIE-ECHOED—the packet violates the SCTP state machine and is dropped. This typically indicates a peer implementation error, out-of-order packet delivery, asymmetric routing causing the firewall to miss earlier shutdown messages, or an attack attempting to disrupt established associations.

Recommendation:

Verify that both SCTP endpoints are RFC 4960 compliant and properly implementing graceful shutdown. Check for asymmetric routing or packet loss that might cause the firewall to miss the initial SHUTDOWN message. If the counter increments frequently for legitimate traffic, ensure all packets in the SCTP association traverse the same firewall (avoid asymmetric paths). Review SCTP inspection configuration—if stateful inspection is not required, consider using 'set connection advanced-options sctp-state-bypass' to bypass state validation. Capture packets around the time of the drop to determine whether the peer is sending SHUTDOWN-ACK prematurely or whether the firewall missed earlier shutdown messages due to routing changes. Persistent drops from a single peer may indicate a faulty SCTP stack.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-shutdown-ack-no-assoc

SCTP SHUTDOWN-ACK received without matching association

The firewall received an SCTP SHUTDOWN-ACK chunk but could not find a matching SCTP association to process it. SCTP uses a three-way graceful shutdown handshake (SHUTDOWN → SHUTDOWN-ACK → SHUTDOWN-COMPLETE), and this drop occurs when the SHUTDOWN-ACK arrives after the firewall has already removed the association from its state table. This typically happens due to timing issues during connection teardown: the association may have already completed shutdown and been cleaned up, timed out due to inactivity, or been removed during a failover or reload event. It can also occur in asymmetric routing scenarios where the firewall did not see the original association establishment and therefore has no state to match against the shutdown message. SCTP is commonly used in telecom and carrier environments for signaling protocols such as Diameter and SS7/M3UA.

Recommendation:

This drop is usually benign and indicates normal race conditions during SCTP connection teardown. No action is required if connections are establishing and tearing down successfully. If you see persistent or high-volume occurrences, verify that SCTP inspection is enabled if required for your deployment (check 'show service-policy' and 'show sctp' output), confirm that both directions of SCTP traffic are traversing the same firewall (asymmetric routing can prevent proper state tracking), and review association timeout settings if associations are being removed prematurely. Check for recent failover or reload events that would have cleared association state. If SCTP applications are experiencing connectivity issues alongside these drops, collect 'show sctp' output and contact TAC for further analysis.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-shutdown-comp-no-assoc

SCTP SHUTDOWN-COMPLETE received without active association

This counter increments when the firewall receives an SCTP SHUTDOWN-COMPLETE chunk but cannot find a matching SCTP association in its state table. The SHUTDOWN-COMPLETE chunk is the final message in SCTP's graceful connection teardown sequence, sent by an endpoint to acknowledge the completion of association termination. This drop typically occurs due to timing conditions: the association may have already been removed due to timeout, the firewall may have cleaned up the association state before the SHUTDOWN-COMPLETE arrived, or the packet may be a delayed or duplicate transmission. In asymmetric routing scenarios, the SHUTDOWN-COMPLETE may arrive at a firewall that never tracked the original association. This condition is most commonly seen in telecom and carrier environments using SCTP for signaling protocols such as Diameter, SS7, or M3UA.

Recommendation:

This drop is typically benign and represents correct firewall behavior—rejecting a termination message for a connection that no longer exists. No action is required in most cases. If you observe a high rate of these drops, investigate whether SCTP associations are being prematurely timed out or if there are asymmetric routing issues causing SHUTDOWN-COMPLETE messages to arrive at the wrong firewall. Use 'show sctp' to verify active associations and their states. Review SCTP timeout configuration if associations appear to be timing out before graceful shutdown completes. If the drops correlate with application connectivity issues, collect packet captures to verify the complete SCTP shutdown sequence and contact Cisco TAC for further analysis.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-shutdown-complete-in-invalid-state

SCTP SHUTDOWN-COMPLETE received in wrong association state

The firewall dropped an SCTP SHUTDOWN-COMPLETE chunk because the association was not in the expected SHUTDOWN-ACK-SENT state. During normal SCTP graceful shutdown, the sequence is: one endpoint sends SHUTDOWN → peer responds with SHUTDOWN-ACK (transitioning to SHUTDOWN-ACK-SENT state) → original endpoint sends SHUTDOWN-COMPLETE to finalize termination. This counter increments when SHUTDOWN-COMPLETE arrives while the association is in any state other than SHUTDOWN-ACK-SENT (for example, ESTABLISHED, COOKIE-WAIT, SHUTDOWN-SENT, or CLOSED). Common causes include: out-of-order packet delivery causing the SHUTDOWN-ACK to arrive after the SHUTDOWN-COMPLETE; asymmetric routing where the firewall sees only one direction of the shutdown handshake; retransmitted or delayed SHUTDOWN-COMPLETE chunks arriving after the association has already been torn down; or endpoints that violate the RFC 4960 shutdown state machine (such as sending SHUTDOWN-COMPLETE without first receiving SHUTDOWN-ACK). This drop protects the firewall's SCTP state tracking from invalid transitions.

Recommendation:

Capture packets on both sides of the firewall during the SCTP association teardown to verify the complete shutdown sequence. Check for packet loss, reordering, or asymmetric routing that might cause the firewall to miss the SHUTDOWN-ACK chunk. If the counter increments frequently for a specific SCTP application, verify that the endpoints correctly implement RFC 4960 graceful shutdown procedures. Use 'show sctp' to inspect current association states and identify which associations are experiencing shutdown issues. If the application uses SCTP multi-homing, ensure all paths are stable and not causing split-brain scenarios where different shutdown messages traverse different paths. For telecom/signaling applications (Diameter, M3UA, SIGTRAN), coordinate with the application vendor to confirm proper SCTP stack behavior. If drops occur only during failover or high-availability events, review the timing of state synchronization between firewall peers. Occasional drops during network instability are expected and benign; persistent drops indicate either a misbehaving SCTP endpoint or a network topology issue preventing the firewall from seeing the complete shutdown handshake.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-shutdown-in-invalid-state

SCTP SHUTDOWN received during connection establishment

The firewall received an SCTP SHUTDOWN chunk while the association was still in the initial handshake phase (COOKIE-WAIT or COOKIE-ECHOED state), before the four-way handshake completed. This violates the SCTP protocol specification, which requires associations to reach ESTABLISHED state before graceful shutdown can begin. The SHUTDOWN chunk is dropped and removed from the packet; if other valid chunks remain in the same packet, they are processed normally. This typically indicates a peer implementation error, severe packet reordering, or malformed traffic. COOKIE-WAIT means the local endpoint sent an INIT and is waiting for the INIT-ACK response; COOKIE-ECHOED means the local endpoint received the INIT-ACK (containing a state cookie) and sent a COOKIE-ECHO, but has not yet received the COOKIE-ACK that would complete the handshake and transition to ESTABLISHED state.

Recommendation:

Occasional drops are usually benign and indicate transient network conditions or a peer that prematurely attempted shutdown. If drops are frequent or persistent: (1) Verify the remote SCTP endpoint implementation is RFC-compliant and not sending SHUTDOWN before the handshake completes. (2) Check for severe packet reordering or delay in the network path that might cause SHUTDOWN chunks from a previous connection attempt to arrive during a new handshake. (3) Use 'show sctp' to verify association states are progressing normally through COOKIE-WAIT → COOKIE-ECHOED → ESTABLISHED. (4) Review SCTP inspection configuration; if stateful inspection is not required, consider 'sctp-state-bypass' to reduce sensitivity to protocol anomalies. (5) If the remote peer is a known-good implementation and drops persist, capture traffic on both sides of the firewall to identify whether the peer is actually sending invalid SHUTDOWN chunks or if middlebox behavior is reordering packets. Contact TAC if drops correlate with application failures.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-shutdown-no-assoc

SCTP SHUTDOWN received without tracked association

The firewall received an SCTP SHUTDOWN chunk but has no record of the association being terminated. SCTP inspection maintains stateful tracking of associations through the four-way handshake (INIT/INIT-ACK/COOKIE-ECHO/COOKIE-ACK). A SHUTDOWN chunk is part of the graceful teardown sequence and should only arrive for an established association. This counter increments when SHUTDOWN arrives but the firewall has no matching association state—either because the association was never established through this firewall, the association was already closed and removed from the state table, or the firewall restarted and lost session state. This can also occur with asymmetric routing where the INIT handshake traversed a different path.

Recommendation:

This drop is typically benign and represents normal protection against malformed or out-of-context signaling. Investigate if the counter increments rapidly or correlates with application failures. Check for asymmetric routing using 'packet-tracer' to verify both directions of SCTP flows traverse the same firewall. Review 'show sctp' to confirm expected associations are tracked. If associations are not appearing, verify SCTP inspection is enabled with 'show service-policy inspect sctp' and that the carrier license is active. After a firewall reload or failover, this counter may increment as peers attempt to close associations that no longer exist in the state table—this is expected and the peers will eventually time out and re-establish. If the counter grows continuously during normal operation, capture traffic to determine whether SHUTDOWN chunks are arriving for legitimate associations that the firewall failed to track, which may indicate an inspection issue requiring TAC assistance.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-shutdown-too-small

SCTP SHUTDOWN chunk length is too small

The firewall received an SCTP SHUTDOWN chunk with a length field smaller than the minimum required size. According to RFC 4960, a valid SHUTDOWN chunk must be exactly 8 bytes: a 4-byte chunk header followed by a 4-byte Cumulative TSN Acknowledgment field. This drop indicates the received chunk does not meet this requirement, suggesting either a malformed packet from a non-compliant SCTP implementation, network corruption, or potentially malicious traffic. The firewall drops these packets to prevent protocol parsing errors and potential security vulnerabilities. This validation occurs during the graceful SCTP association termination sequence when processing SHUTDOWN chunks in ESTABLISHED, SHUTDOWN_PENDING, or SHUTDOWN_SENT states.

Recommendation:

Investigate the source of the malformed SCTP traffic. Check whether the SCTP endpoint sending the SHUTDOWN chunk is using a compliant implementation and is not experiencing software bugs or configuration issues. If the traffic is legitimate, contact the vendor of the SCTP application to report the protocol violation. Verify that no network devices between the endpoints are corrupting packets (check for MTU issues, faulty hardware, or middleboxes improperly modifying SCTP packets). If you observe this counter incrementing frequently from a specific source, consider whether the traffic may be malicious scanning or exploit attempts. Capture packets using 'capture' commands to examine the actual SHUTDOWN chunk structure and length field. This drop is a security protection and should not be disabled; legitimate SCTP implementations will not trigger this counter.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-too-small

SCTP chunk length field is invalid or smaller than minimum header size

The firewall received an SCTP packet containing a chunk with an invalid length field. Each SCTP chunk must include a 4-byte header (type, flags, and length), and the length field must be at least 4 bytes. This counter increments when the firewall detects a chunk whose declared length is less than 4 bytes, or when the remaining packet data is insufficient to contain a complete chunk header. This validation protects against malformed or malicious SCTP packets that could exploit buffer handling vulnerabilities. The counter also increments if an SCTP packet contains no chunks at all (empty datagram after the common header). This drop typically indicates either network corruption, a misconfigured SCTP endpoint, or an attempted attack using crafted packets. Legitimate SCTP traffic should never trigger this drop under normal conditions.

Recommendation:

Investigate the source of the malformed SCTP traffic. If the source is a known legitimate endpoint, verify that the SCTP implementation is RFC-compliant and not corrupted. If the traffic originates from untrusted networks or unknown sources, this may indicate reconnaissance or an exploit attempt—review security policies and consider blocking the source. Capture the dropped packets using 'capture' with 'asp-drop' to examine the malformed chunk structure. If legitimate SCTP associations are failing and you suspect a software issue, collect packet captures and contact Cisco TAC. This drop should not occur with properly formed SCTP traffic from compliant implementations.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-unexpected

SCTP chunk received in invalid association state

The firewall dropped an SCTP packet because it contained a control chunk that is not valid for the current state of the SCTP association. This occurs during SCTP association establishment or teardown when the firewall receives chunks with verification tags or state combinations that violate the SCTP protocol state machine. Common scenarios include receiving SHUTDOWN or ABORT chunks with verification tags that don't match the expected association state, or receiving control chunks when no valid association context exists. This is typically caused by out-of-order packets, connection resets, or peers that are not properly synchronized on association state.

Recommendation:

This counter usually indicates normal protocol behavior during connection failures or resets. Review the SCTP traffic pattern to determine if associations are failing to establish properly. If the counter increments frequently, check for: (1) network issues causing packet loss or reordering during SCTP handshakes, (2) application or peer issues causing premature connection resets, (3) asymmetric routing where the firewall sees only one direction of the SCTP handshake. Use 'show sctp' to view current association states and 'capture' with SCTP filters to examine the chunk types and verification tags in dropped packets. If associations are establishing successfully despite these drops, the counter reflects normal handling of stale or duplicate control chunks and no action is needed.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-unrec-param

SCTP chunk contains unrecognizable parameter requiring termination

This counter increments when the firewall receives an SCTP INIT or INIT-ACK chunk containing an optional parameter with an unrecognized type code, and that parameter's action bits (the two highest-order bits of the parameter type field) indicate that processing must stop and the chunk must be rejected. According to RFC 4960, SCTP parameter types encode handling instructions: when the high-order bits are set to '11' (binary), the receiver must stop processing the chunk and discard the packet. This is distinct from parameters that can be safely skipped. The drop occurs during the four-way handshake when establishing a new SCTP association, typically when one endpoint advertises an extension or feature that the firewall does not recognize and that the sender has marked as mandatory. Common scenarios include proprietary SCTP extensions, newer RFC-defined parameters not yet supported by the firewall software version, or malformed parameter type values. The firewall may send an ABORT chunk with an 'Unrecognized Parameters' error back to the sender before dropping the packet.

Recommendation:

This drop is typically benign and indicates correct protocol enforcement—the firewall is rejecting association setup that requires unsupported mandatory features. If SCTP associations are failing to establish: (1) Verify both SCTP endpoints are using compatible protocol extensions and feature sets; check vendor documentation for any proprietary SCTP parameters in use. (2) Review the SCTP endpoint configurations to disable optional extensions that are not essential for the application (such as authentication, dynamic address reconfiguration, or partial reliability extensions). (3) Capture packets on both sides of the firewall to identify which specific parameter type is triggering the drop; the parameter type field in the INIT or INIT-ACK chunk will show the unrecognized value. (4) If the parameter represents a legitimate newer SCTP feature, consider upgrading the firewall software to a version that supports it. (5) If drops persist and associations cannot be established, verify that SCTP inspection is necessary for your deployment; if stateful inspection is not required, consider using a simple permit rule instead of 'inspect sctp'. Contact Cisco TAC if legitimate SCTP traffic is being blocked and endpoint configuration changes are not feasible.

Syslogs:

None

----------------------------------------------------------------

sctp-chunk-zero-ver-tag

SCTP packet with zero verification tag in non-INIT/ABORT/SHUTDOWN-COMPLETE chunk

This counter increments when an SCTP packet arrives with a verification tag of zero in a chunk type that is not permitted to use zero. According to RFC 4960, only INIT chunks, certain ABORT chunks, and SHUTDOWN-COMPLETE chunks (without the T-bit) may carry a zero verification tag. All other SCTP chunk types—including DATA, SACK, HEARTBEAT, COOKIE-ECHO, and others—must carry a non-zero verification tag that matches the association state. A zero tag in these chunks indicates either a malformed packet, a protocol implementation error on the sender, or a potential spoofing attempt. This drop protects the SCTP state machine from processing packets that violate the protocol's association integrity checks.

Recommendation:

This drop typically indicates a problem with the remote SCTP endpoint or an intermediary device corrupting SCTP headers. Verify that both endpoints implement RFC 4960 correctly and that no middlebox is modifying SCTP verification tags. If the remote endpoint is a telecom signaling gateway (Diameter, SIGTRAN/M3UA), check for firmware updates or misconfigurations. Capture packets on both sides of the firewall to determine whether the zero tag originates from the sender or is introduced in transit. If drops occur during normal operation with known-good endpoints, contact Cisco TAC with packet captures showing the SCTP common header and chunk types.

Syslogs:

None

----------------------------------------------------------------

sctp-data-chunk-in-invalid-state

SCTP DATA chunk received in invalid association state

The firewall dropped an SCTP packet containing a DATA chunk because the SCTP association was not in a state that accepts user data. This occurs when DATA chunks arrive during connection establishment (before the four-way handshake completes), during graceful shutdown sequences (after SHUTDOWN has been sent or received), after the association has closed, or during high-availability failover synchronization. The SCTP protocol state machine only permits DATA chunks in the ESTABLISHED state; control chunks (INIT, COOKIE-ECHO, SHUTDOWN, etc.) are used for all other phases. This drop is typically caused by retransmitted DATA chunks that arrive after one endpoint has initiated shutdown, by out-of-order packets during connection setup, or by stale data arriving after an association has been torn down and the firewall has already transitioned to CLOSED state.

Recommendation:

This counter usually indicates normal protocol behavior rather than a problem. Common scenarios include: (1) The remote endpoint retransmitting DATA chunks after the local side has already sent SHUTDOWN, which is expected during graceful connection teardown. (2) DATA chunks arriving before the SCTP four-way handshake completes, typically due to aggressive applications that send data immediately after INIT without waiting for COOKIE-ACK. (3) Delayed packets arriving after an association timeout or reset. If this counter increments steadily during normal operation, verify that SCTP applications are properly waiting for the ESTABLISHED state before sending data, and check for network conditions causing significant packet delay or reordering. If the counter increments during high-availability events, this is expected behavior during failover synchronization. Use 'show sctp' to view current association states and 'show service-policy inspect sctp' to correlate drops with specific traffic flows. No action is typically required unless application-level failures are observed.

Syslogs:

None

----------------------------------------------------------------

sctp-data-chunk-len-exceeds-rwnd

SCTP DATA chunk received when receive window is zero

This counter increments when the firewall receives an SCTP DATA chunk for an association whose advertised receive window is currently zero. The receive window represents the amount of buffer space available at the receiving endpoint to accept new data. When this window reaches zero, the receiver has signaled through SACK (Selective Acknowledgment) messages that it cannot accept additional data until it processes buffered data and frees up space. If a sender transmits DATA chunks despite a zero receive window advertisement, the firewall drops the packet to enforce SCTP flow control. This typically occurs in one of three scenarios: the sender has not yet processed the zero-window advertisement due to timing or network delay; the sender is misbehaving and ignoring flow control signals; or there is asymmetric processing where one SCTP endpoint is overwhelmed and unable to keep pace with incoming data. This drop is most commonly seen in telecom and carrier environments running SCTP-based signaling protocols such as Diameter or M3UA (SS7 over IP), particularly under high connection rates or when application-layer processing on one endpoint is delayed.

Recommendation:

Verify that both SCTP endpoints are operating normally and that the receiving endpoint is not overloaded or experiencing application-layer delays that prevent it from processing buffered data. Check the output of 'show sctp' to examine the current receive window values and association state for affected flows. If the drops are persistent, investigate whether the receiving application is keeping pace with incoming traffic or if there are resource constraints (CPU, memory, or application processing delays) on the endpoint advertising the zero window. In environments with legitimate high-volume SCTP signaling traffic, ensure that endpoint buffer sizes and processing capacity are appropriately sized for the traffic load. If the sender is a third-party system, verify that it correctly implements SCTP flow control per RFC 4960 and respects zero-window advertisements. Occasional drops during traffic bursts may be normal and self-correcting as the receiver catches up; sustained drops indicate a capacity or implementation issue at one of the endpoints.

Syslogs:

None

----------------------------------------------------------------

sctp-data-chunk-len-invalid

SCTP DATA chunk length exceeds packet boundary

The firewall received an SCTP packet containing a DATA chunk whose length field indicates the chunk extends beyond the actual packet boundary. This occurs when the chunk header specifies a length that would read past the end of the received packet data. This is a malformed packet condition that can result from network corruption, packet truncation during transmission, or maliciously crafted traffic attempting to exploit protocol parsing vulnerabilities. The firewall drops the entire packet to prevent processing invalid data and to protect against potential buffer overrun attacks. SCTP inspection validates all chunk boundaries before processing to ensure protocol compliance and system stability.

Recommendation:

This counter typically indicates malformed or corrupted SCTP traffic reaching the firewall. Investigate the source of the invalid packets: check for network transmission issues, faulty SCTP implementations on endpoints, or potential attack traffic. Capture the dropped packets using 'capture asp-drop sctp-data-chunk-len-invalid' to examine the malformed chunk headers. If drops are persistent from legitimate SCTP endpoints (such as Diameter, SIGTRAN, or M3UA signaling servers), verify the endpoint software versions and check for known bugs in their SCTP stack implementations. Occasional drops may be benign if caused by transient network issues, but sustained drops from production signaling infrastructure require investigation. Contact Cisco TAC if legitimate SCTP associations fail to establish due to these drops.

Syslogs:

None

----------------------------------------------------------------

sctp-data-chunk-len-too-small

SCTP DATA chunk has no payload

This counter increments when the firewall receives an SCTP DATA chunk that contains only headers with no actual user data payload. According to RFC 4960, SCTP DATA chunks must carry user data; a DATA chunk consisting of only the 20-byte header structure (chunk header plus DATA chunk metadata fields like TSN, stream ID, sequence number, and protocol ID) without any payload is malformed and violates the protocol specification. The firewall drops these packets to prevent potential exploitation of SCTP inspection engines (such as Diameter or M3UA inspection) and to enforce protocol compliance. This drop typically occurs when SCTP traffic is being inspected or when SCTP associations are actively managed by the firewall.

Recommendation:

Investigate the source of the malformed SCTP packets. Common causes include: (1) A buggy or non-compliant SCTP implementation on the sending endpoint that is generating invalid DATA chunks, (2) Malicious traffic attempting to exploit SCTP inspection or trigger resource exhaustion, or (3) Network corruption or middlebox interference that is truncating SCTP packets. Capture and analyze the dropped packets using packet capture to identify the source IP and SCTP association. If the traffic is from a legitimate application, contact the application vendor to report the protocol violation. If the traffic appears malicious or from an untrusted source, verify that appropriate access controls are in place. This drop is a security protection and should not be bypassed; legitimate SCTP applications will not generate empty DATA chunks.

Syslogs:

None

----------------------------------------------------------------

sctp-dgram-header-unavailable

SCTP datagram header allocation failed

The firewall dropped an SCTP packet because it could not allocate a datagram header structure needed to track fragment reassembly or stream reordering. Each SCTP association maintains a pool of datagram headers to manage incoming DATA chunks that arrive fragmented or out-of-order across multiple streams. When a new fragment or out-of-order chunk arrives and no pre-allocated header is available, the packet is dropped. This typically occurs under memory pressure or when the SCTP association has exhausted its internal datagram tracking resources due to a large number of concurrent incomplete datagrams awaiting reassembly or reordering.

Recommendation:

This counter indicates resource exhaustion within SCTP inspection. Check memory utilization on the device using 'show memory' and 'show blocks'. Review SCTP connection state with 'show conn protocol sctp detail' to identify associations with excessive reassembly queues. If the counter increments frequently, consider: (1) investigating whether SCTP endpoints are sending excessive fragmented traffic or out-of-order streams, (2) checking for slow SCTP receivers that may cause reassembly queue buildup, (3) verifying that SCTP traffic patterns are within expected norms for your deployment (mobile signaling, Diameter, SS7/M3UA). The firewall enforces per-core limits on concurrent datagram reassembly (125 datagrams) and per-queue fragment limits (10 fragments) to prevent resource exhaustion. If legitimate traffic is being dropped, contact Cisco TAC to evaluate whether SCTP inspection tuning or platform sizing adjustments are needed.

Syslogs:

None

----------------------------------------------------------------

sctp-drop-fixme

SCTP inspection drop overridden

This counter increments when SCTP inspection would normally drop a packet due to an application-layer policy violation, but the drop is overridden to preserve SCTP protocol integrity. The firewall overrides the drop when the packet contains SCTP control chunks (such as INIT, COOKIE-ECHO, HEARTBEAT, or ABORT) or multiple DATA chunks that must be processed to maintain the SCTP association state machine. This behavior prevents application inspection policies from breaking valid SCTP associations by dropping critical control signaling. The packet is allowed to continue, and only the violating application data may be selectively removed while preserving control chunks.

Recommendation:

This counter is informational and indicates normal operation when SCTP inspection is enabled with application-layer policies (such as Diameter inspection). The firewall is correctly prioritizing SCTP transport-layer integrity over application-layer policy enforcement. If this counter increments, verify that application inspection policies are configured as intended—some application data may be passing that would otherwise be dropped if it were not bundled with control chunks. To see detailed SCTP inspection statistics including drop-override counts, use 'show service-policy inspect sctp'. No action is typically required unless you observe SCTP association failures, in which case review SCTP inspection configuration and other SCTP-related drop counters.

Syslogs:

None.

----------------------------------------------------------------

sctp-duplicate-data-stream

Duplicate SCTP DATA chunk received

The firewall received an SCTP DATA chunk that has already been processed and acknowledged. This occurs when the SCTP sender retransmits a DATA chunk (identified by its Transmission Sequence Number or TSN) that the firewall has already received, acknowledged, and either delivered to the application or queued for stream reordering. The firewall drops the duplicate to prevent processing the same data twice. This is normal SCTP protocol behavior when network conditions cause packet loss or delay—the sender retransmits DATA chunks that it believes were lost, but the firewall has already received and processed them. The counter may increment during periods of network congestion, packet reordering, or when SCTP endpoints are geographically distant with high latency. For fragmented SCTP messages, this counter also increments when a fragment that is already in the reassembly queue is received again.

Recommendation:

This counter incrementing is typically benign and reflects normal SCTP retransmission behavior in response to network conditions. The firewall correctly drops duplicates to maintain data integrity. Monitor the counter over time: occasional increments are expected, especially in networks with packet loss or high latency. If the counter increases rapidly or continuously, investigate the underlying network for excessive packet loss, congestion, or routing instability between SCTP endpoints. Use 'show sctp' to view active SCTP associations and their statistics. If SCTP applications report performance issues concurrent with high duplicate counts, check for network path problems or mismatched SCTP timeout parameters between endpoints. No configuration change is typically required unless the network path quality needs improvement.

Syslogs:

None

----------------------------------------------------------------

sctp-initack-chunk-inv-state

SCTP INIT-ACK received when association not in COOKIE-WAIT state

The firewall received an SCTP INIT-ACK control chunk for an association that is not in the COOKIE-WAIT state. In the SCTP four-way handshake, INIT-ACK is the second message (sent by the server in response to the client's INIT) and should only arrive when the client is waiting for it after sending an INIT. This counter increments when an INIT-ACK arrives for an association that has already progressed past COOKIE-WAIT (for example, already ESTABLISHED) or is in an unexpected state. Common causes include: delayed or retransmitted INIT-ACK packets arriving after the association has completed the handshake, out-of-order delivery causing INIT-ACK to arrive after COOKIE-ECHO/COOKIE-ACK have already been exchanged, stale INIT-ACK from a previous association attempt using the same endpoints, or a protocol violation by the peer. The firewall enforces strict SCTP state machine compliance and drops packets that violate the expected state transitions.

Recommendation:

This drop is typically benign if it occurs infrequently, as it protects against protocol violations and stale packets. If the counter increments frequently, investigate: (1) Check for network conditions causing significant packet delay or reordering between the firewall and SCTP endpoints. (2) Verify SCTP endpoints are not retransmitting INIT-ACK excessively, which may indicate network instability or endpoint misconfiguration. (3) Review 'show sctp' output to confirm associations are establishing successfully despite the drops—if associations fail to establish, the issue may be more serious. (4) If using SCTP multihoming, ensure all paths have similar latency characteristics to avoid out-of-order delivery. (5) Capture packets on both sides of the firewall to determine whether INIT-ACK is arriving late or if the association state tracking is out of sync. If associations establish normally and the drop rate is low, no action is required. Contact Cisco TAC if associations fail to establish or if the drop rate is high and impacting service.

Syslogs:

None

----------------------------------------------------------------

sctp-invalid-bundle

SCTP packet has control chunks after data chunks

The firewall received an SCTP packet that violates the protocol bundling rules defined in RFC 4960 Section 6.10. The packet contains control chunks (such as SACK, HEARTBEAT, SHUTDOWN, or other signaling chunks) positioned after data chunks within the same SCTP packet. According to the SCTP specification, when multiple chunks are bundled into a single packet, all control chunks must appear before any data chunks. This counter increments when the firewall detects this ordering violation during packet validation and drops the malformed packet. This drop typically indicates a misbehaving SCTP endpoint, a middlebox that is incorrectly modifying SCTP packets, or rarely, packet corruption in transit. The drop occurs during SCTP inspection when the 'inspect sctp' policy is applied to the traffic class.

Recommendation:

Verify that both SCTP endpoints are using compliant SCTP protocol stacks. Check for any middleboxes (load balancers, proxies, or other firewalls) between the endpoints that might be modifying SCTP packets incorrectly. If the traffic is legitimate and the endpoints are known-good implementations, capture the dropped packets using 'capture' with 'asp-drop' to examine the exact chunk ordering. In carrier/telecom environments using SCTP for signaling (Diameter, SIGTRAN/M3UA), coordinate with the application vendor to investigate whether a software bug is causing malformed packet generation. If the drops are infrequent and SCTP associations are establishing successfully, the issue may be transient corruption and can be monitored. Persistent drops that prevent association establishment require vendor engagement to fix the sending application.

Syslogs:

None

----------------------------------------------------------------

sctp-invalid-fragments

SCTP invalid fragments received

This counter increments when SCTP inspection detects malformed or out-of-sequence fragment chunks during reassembly of fragmented SCTP data messages. SCTP fragmentation allows large application messages to be split across multiple DATA chunks, each identified by a Transmission Sequence Number (TSN) and marked with begin, middle, or end flags. The firewall validates fragment sequences to ensure proper reassembly. Invalid conditions include: receiving multiple begin fragments with different TSNs (indicating conflicting message starts), multiple end fragments with different TSNs, or fragments with TSNs outside the expected sequence range for the message being reassembled. When an invalid fragment is detected, the firewall drops the offending fragment to prevent corrupted message delivery. This counter typically appears when SCTP inspection is enabled for signaling protocols such as Diameter or SS7/M3UA in carrier and telecom environments.

Recommendation:

This drop usually indicates malformed SCTP traffic from the sender or possible network corruption affecting fragment delivery. Verify that SCTP endpoints are functioning correctly and not sending duplicate or misordered fragments. Check for network issues that might cause packet reordering or duplication between the sender and the firewall. If the drops are frequent and affecting legitimate traffic, capture packets on both sides of the firewall to identify whether the sender is transmitting invalid fragment sequences or if network conditions are causing the problem. In most cases, these drops protect against malformed SCTP traffic and do not require action unless legitimate SCTP associations are failing to establish or transfer data.

Syslogs:

None

----------------------------------------------------------------

sctp-no-association

SCTP no association

The firewall received an SCTP packet containing a DATA chunk, but could not find a matching SCTP association for the packet's verification tag and address tuple. SCTP associations are created during the four-way handshake (INIT, INIT-ACK, COOKIE-ECHO, COOKIE-ACK) and are identified by verification tags exchanged during setup. This drop occurs when DATA arrives before the association is fully established, after the association has been torn down, when the verification tag does not match any known association, or when association state is missing due to failover or clustering events. The drop is also expected during normal connection teardown when one endpoint continues sending data after the other has closed the association.

Recommendation:

This counter typically indicates one of several conditions: (1) The SCTP client or server is sending data before completing the four-way handshake—verify that applications properly wait for association establishment. (2) One endpoint is sending data after the association has been closed—check application logic for proper shutdown sequencing. (3) In high-availability or clustering deployments, association state may not have synchronized to the standby or backup unit—verify cluster health and check for defects related to SCTP state replication (such as CSCuv60284 or CSCuv83182). (4) Packets are arriving out of order or being replayed—examine network conditions for packet loss or duplication. If the counter increments during normal traffic and associations are failing to establish, capture packets on both sides of the firewall to determine whether the handshake is completing successfully. For clustered deployments experiencing this drop after failover, ensure all units are running compatible software versions with SCTP clustering fixes. If drops occur persistently during active data transfer, contact Cisco TAC with packet captures and the output of 'show sctp' and 'show asp drop'.

Syslogs:

None

----------------------------------------------------------------

sctp-pkt-auth-chunk-extra

SCTP packet contains multiple AUTH chunks

The firewall dropped an SCTP packet because it contained more than one Authentication (AUTH) chunk. RFC 4895 specifies that an SCTP packet may contain at most one AUTH chunk to authenticate the other chunks in the packet. Multiple AUTH chunks in a single packet represent a protocol violation and indicate either a malformed packet, a misconfigured SCTP endpoint, or a potential attack attempting to bypass authentication validation. This counter increments during SCTP stateful inspection when the packet validation detects this condition. The drop protects against ambiguous authentication scenarios where it would be unclear which AUTH chunk should be used to validate the packet contents.

Recommendation:

This drop typically indicates a problem with the SCTP endpoint implementation or configuration. Verify that both SCTP endpoints are RFC 4895 compliant and properly configured for SCTP authentication. If the traffic is legitimate, check the sending application or SCTP stack for bugs or misconfigurations that might cause it to bundle multiple AUTH chunks. If drops persist from a specific source, capture packets to confirm whether multiple AUTH chunks are actually present. This is not normal SCTP behavior and may indicate a security issue or faulty implementation. Contact the vendor of the SCTP application if the issue cannot be resolved through configuration changes.

Syslogs:

None

----------------------------------------------------------------

sctp-pkt-auth-chunk-no-data

SCTP packet contains only AUTH chunks

The device received an SCTP packet that contains only authentication (AUTH) chunks with no other chunk types present. SCTP authentication chunks are designed to authenticate other chunks in the same packet, such as DATA, INIT, or control chunks. A packet containing exclusively AUTH chunks violates the SCTP authentication extension specification because there is no payload to authenticate. This typically indicates a malformed packet, a protocol implementation error in the peer endpoint, or potentially malicious traffic. SCTP is commonly used for signaling protocols such as M3UA (SS7 over IP) and Diameter (AAA signaling), where authentication may be enabled for security. The device drops these packets during the validation phase before further processing.

Recommendation:

This drop usually indicates a problem with the remote SCTP endpoint implementation. Verify that the peer device is correctly implementing SCTP authentication (RFC 4895) and is not sending malformed packets. Check whether the peer is running current software with known SCTP fixes. If the traffic is legitimate signaling (M3UA, Diameter, or similar), review the peer's SCTP authentication configuration to ensure AUTH chunks are properly bundled with data or control chunks. Capture the dropped packets to confirm they contain only AUTH chunks with no other chunk types. If drops persist and impact service, contact the vendor of the peer SCTP endpoint. This drop is a protocol violation and should not occur in normal operation.

Syslogs:

None

----------------------------------------------------------------

sctp-pkt-partial_chunk

SCTP packet contains incomplete chunk

The firewall dropped an SCTP packet because one or more chunks in the packet appear truncated or extend beyond the packet boundary. SCTP chunks must be complete within a single packet and properly padded to 32-bit alignment per RFC 4960. This drop typically indicates packet corruption in transit, IP fragmentation issues affecting SCTP packets, or a non-compliant SCTP implementation that incorrectly calculates chunk lengths or padding. The firewall validates that each chunk's declared length (including required padding) fits entirely within the received packet; if a chunk appears to extend past the end of the packet, the entire packet is dropped to prevent processing malformed protocol data. Note that COOKIE-ECHO chunks that are the sole chunk in a packet are permitted even with minor padding discrepancies to accommodate certain SCTP implementations.

Recommendation:

Verify that IP fragmentation is not occurring on SCTP traffic—SCTP packets should not be fragmented at the IP layer, as this can cause the firewall to see incomplete chunks. Check the MTU configuration on all devices in the path and ensure SCTP endpoints are performing proper path MTU discovery. If the SCTP endpoints are multihomed (multiple IP addresses per endpoint) and NAT is configured, verify that all addresses are properly translated. Capture packets on both sides of the firewall to determine whether the truncation is occurring before or after the firewall. If the issue persists with a specific SCTP implementation, the remote endpoint may have a bug in chunk length calculation or padding—consult the vendor of the SCTP application. This drop is a legitimate protocol validation failure and should not occur with compliant SCTP implementations under normal conditions.

Syslogs:

None

----------------------------------------------------------------

sctp-pkt-too-small

SCTP packet smaller than minimum valid size

The firewall received an SCTP packet that is too small to contain a valid protocol structure. Every SCTP packet must include at minimum a 12-byte common header (source port, destination port, verification tag, and checksum) plus at least one 4-byte chunk header, for a total minimum size of 16 bytes. Packets smaller than this threshold are malformed and cannot be processed. This counter increments when the firewall detects and drops such undersized packets during the initial validation stage, before any stateful inspection occurs. This condition typically indicates network corruption, fragmentation issues, truncated packets, or potentially malicious traffic attempting to exploit protocol parsing vulnerabilities.

Recommendation:

This drop reason protects against malformed traffic and is expected behavior. Investigate the source of the undersized packets: check for network equipment that may be corrupting or truncating SCTP traffic, misconfigured MTU settings causing improper fragmentation, or security scanning tools generating malformed probe packets. Capture traffic on both sides of the firewall to determine where truncation occurs. If the source is legitimate SCTP application traffic, verify that the sending application is correctly implementing the SCTP protocol. Persistent increments from production traffic sources may indicate a software defect in the SCTP stack of the sending system. This drop does not indicate a firewall misconfiguration and cannot be disabled.

Syslogs:

None

----------------------------------------------------------------

sctp-reassembly-buffer-size-limit

SCTP Fragment Reassembly Buffer Limit Exceeded

The firewall dropped fragmented SCTP DATA chunks because the total size of fragments being reassembled for a single message exceeded the 8192-byte buffer limit. This counter increments when SCTP inspection is enabled and the device receives either a single fragment larger than 8192 bytes or a sequence of fragments that together exceed this limit. When the limit is reached, all fragments for that message are discarded from the reassembly queue. This protection prevents excessive memory consumption during SCTP fragment reassembly, which is commonly used in mobile network signaling protocols like Diameter and SS7/M3UA that run over SCTP transport. The limit applies independently to both ordered and unordered SCTP streams within an association.

Recommendation:

This drop typically indicates that an SCTP endpoint is sending unusually large fragmented messages that exceed the firewall's reassembly capacity. First, verify that SCTP inspection is required for your traffic using 'show service-policy' and 'show conn detail' to identify SCTP flows. If SCTP inspection is necessary (for example, to inspect Diameter or M3UA signaling), investigate why messages are being fragmented so heavily—check the path MTU between endpoints and consider whether the sending application can reduce message sizes or adjust its fragmentation behavior. If legitimate traffic is being dropped, you may need to work with the application vendor to optimize message sizes. Note that the 8192-byte limit is fixed and cannot be adjusted. If drops are infrequent and do not impact service, they may be acceptable as a trade-off for memory protection. Contact Cisco TAC if you observe sustained drops affecting critical signaling traffic.

Syslogs:

None

----------------------------------------------------------------

sctp-reassembly-queue-limit

SCTP Reassembly Queue Limit Exceeded

This counter increments when SCTP inspection drops fragmented DATA chunks because a single message has been split into more than 6 fragments. SCTP allows large application messages to be fragmented across multiple DATA chunks for transmission. The firewall maintains a reassembly queue for each incomplete message to reconstruct the original data before inspection. When a message exceeds 6 fragments in the reassembly queue, all fragments for that message are discarded and this counter increments. This limit protects the firewall from resource exhaustion due to excessive fragment queuing, whether from legitimate large messages or malicious fragment flooding attacks.

Recommendation:

If this counter increments occasionally, it may indicate legitimate application traffic with unusually large SCTP messages that exceed the fragment limit. If the counter increments frequently or continuously, investigate whether the SCTP traffic is legitimate or part of an attack. Check the source and destination of the dropped traffic using packet captures or connection logs. For legitimate traffic, consider whether the sending application can be configured to use smaller message sizes that require fewer fragments. If the traffic appears malicious (random sources, flood patterns), apply access control lists to block the source addresses or consider rate-limiting SCTP traffic. Note that this is a per-message limit; the firewall can simultaneously reassemble multiple messages as long as each stays within the 6-fragment limit.

Syslogs:

None

----------------------------------------------------------------

sctp-reassembly-queue-timeout

SCTP Reassembly Queue Timeout

Fragmented SCTP data chunks are dropped when reassembly does not complete within 30 seconds. When SCTP inspection receives the first fragment of a multi-fragment message, it starts a reassembly timer and queues the fragment. If subsequent fragments do not arrive within the timeout period, all queued fragments for that message are discarded and this counter increments. This typically occurs when packet loss prevents complete message delivery, when network congestion causes excessive delay between fragments, or when an SCTP peer sends incomplete fragment sequences. The timeout protects the device from holding incomplete fragments indefinitely, which would otherwise consume memory and reassembly queue resources. This counter is relevant only when SCTP inspection is enabled and the device is processing fragmented SCTP traffic, commonly seen in carrier and telecom signaling applications such as Diameter and SS7/M3UA.

Recommendation:

Investigate the SCTP association and network path between endpoints. Check for packet loss, high latency, or MTU mismatches that could delay or drop fragments. Use 'show sctp' to view active associations and their state. Review 'show asp drop' for other SCTP-related drops that might indicate broader issues such as 'sctp-reassembly-system-limit' (too many concurrent reassembly operations) or 'sctp-reassembly-q-bytesize-limit' (individual message too large). If the counter increments frequently during normal operation, verify that SCTP endpoints are functioning correctly and not sending malformed or incomplete fragment sequences. Occasional increments may be benign if caused by transient network issues or connection teardowns. If the problem persists and affects legitimate traffic, capture packets on both interfaces to determine whether fragments are being lost in transit or never sent by the peer.

Syslogs:

None

----------------------------------------------------------------

sctp-reassembly-system-limit

SCTP Reassembly System Limit Exceeded

The firewall has reached the maximum number of incomplete SCTP fragmented messages that can be reassembled simultaneously across all SCTP associations and streams. When SCTP inspection is enabled and the device is processing fragmented SCTP DATA chunks, it maintains reassembly queues to reconstruct complete messages before inspection. This counter increments when the global limit of 125 incomplete datagrams per CPU core is exceeded and a new fragmented message arrives. The limit protects the device from resource exhaustion during high-volume SCTP traffic or fragmentation-based attacks. When this limit is reached, the firewall cannot create a new reassembly queue for the incoming fragment. If the fragment is the only SCTP chunk in the packet, the entire packet is dropped. If the packet contains multiple SCTP chunks bundled together, the firewall attempts to repack the packet by removing only the problematic fragment and forwarding the remaining chunks.

Recommendation:

This counter typically indicates one of three conditions: (1) legitimate high-volume SCTP traffic with extensive fragmentation across many associations or streams, (2) a fragmentation-based resource exhaustion attack, or (3) network conditions causing excessive fragmentation. First, verify whether SCTP inspection is required for your deployment—if SCTP signaling protocols (Diameter, M3UA, SS7) are not in use, consider disabling SCTP inspection. If SCTP inspection is necessary, investigate the traffic pattern: check whether fragments are timing out before reassembly completes (indicating network delays or packet loss), examine the number of concurrent SCTP associations and streams, and look for abnormal fragmentation patterns that might indicate an attack. On multi-core platforms, the limit scales with CPU cores (125 incomplete datagrams per core), so the total system capacity depends on your hardware. If legitimate traffic is being dropped, consider whether upstream devices or applications can reduce SCTP message fragmentation. Contact Cisco TAC if drops persist under normal traffic conditions, as this may indicate a capacity planning issue or require tuning for your specific SCTP deployment.

Syslogs:

None.

----------------------------------------------------------------

sctp-reorder-queue-limit

SCTP reorder queue limit exceeded

This counter increments when an out-of-order SCTP DATA chunk is dropped because the receiving stream already has 50 out-of-order chunks queued and waiting for missing sequence numbers. SCTP inspection maintains a separate reorder queue for each stream within an association to handle chunks that arrive out of sequence. When chunks arrive with gaps in their stream sequence numbers, they are held in the queue until the missing chunks arrive to maintain ordered delivery. The 50-chunk-per-stream limit prevents memory exhaustion from excessive out-of-order traffic. This drop typically occurs during network congestion, packet loss, or routing asymmetry that causes significant reordering of SCTP traffic, particularly in high-volume telecom signaling environments (Diameter, SS7/M3UA). Out-of-order chunks are also automatically flushed after a 30-second timeout if the missing chunks never arrive.

Recommendation:

Investigate the underlying network conditions causing excessive packet reordering. Check for congestion, packet loss, or asymmetric routing between SCTP endpoints. Use packet captures to verify whether chunks are arriving significantly out of order. If the traffic is legitimate signaling traffic experiencing transient network issues, the drops may be unavoidable without addressing the network path quality. For persistent issues with high-rate SCTP signaling traffic, verify that network paths are stable and symmetric. If drops occur during normal operation with no apparent network issues, collect troubleshooting data and contact Cisco TAC, as this may indicate an inspection performance issue or misconfiguration.

Syslogs:

None

----------------------------------------------------------------

sctp-reorder-queue-timeout

SCTP reorder queue timeout

The device drops out-of-order SCTP data chunks that have been buffered for 30 seconds waiting for missing sequence numbers. SCTP inspection maintains a reorder queue for each stream to handle data chunks that arrive out of sequence. When chunks arrive with gaps in their stream sequence numbers, the device buffers the later chunks while waiting for the missing ones to arrive. If the missing chunks do not arrive within 30 seconds, the timer expires and all queued chunks for that stream are dropped to prevent indefinite memory consumption. This counter increments for each dropped chunk, including both individual data chunks and reassembled fragments that were held in the reorder queue. This typically occurs when network conditions cause sustained packet loss or severe reordering on SCTP associations, particularly in multi-homed SCTP deployments where path asymmetry can cause extended sequence number gaps.

Recommendation:

Investigate the network path between SCTP endpoints for packet loss, high latency, or severe reordering. Check for routing asymmetry in multi-homed SCTP configurations where different paths have significantly different characteristics. Use 'show sctp' to examine active associations and identify streams with reorder queue activity. If drops occur consistently on specific associations, verify that both SCTP endpoints are functioning correctly and that intermediate network devices are not selectively dropping or delaying SCTP packets. In environments with known high-latency or lossy paths, consider whether SCTP is the appropriate transport protocol for the application. The 30-second timeout is fixed and cannot be adjusted. Occasional drops during brief network events are expected; sustained drops indicate a persistent network or endpoint issue requiring investigation.

Syslogs:

None

----------------------------------------------------------------

sctp-reorder-stream-limit

SCTP reorder queue limit exceeded

The firewall dropped an out-of-order SCTP DATA chunk because the system-wide limit on concurrent stream reorder queues was reached. SCTP supports multiple independent streams within a single association, and each stream can buffer out-of-order packets for resequencing. To prevent memory exhaustion under heavy load or attack conditions, the firewall limits the total number of streams that can simultaneously hold reorder queues to 64 times the number of CPU cores. This counter increments when an out-of-order chunk arrives for a stream that does not yet have a reorder queue, but creating a new queue would exceed the global limit. In-order traffic on the same association continues to flow normally. This protection was introduced in version 9.7.1 and primarily affects environments with SCTP inspection enabled for signaling protocols such as Diameter or M3UA.

Recommendation:

This drop typically indicates one of three conditions: sustained packet reordering across many SCTP streams (common in load-balanced or multi-path network topologies), a burst of new SCTP associations with out-of-order delivery, or a potential denial-of-service attempt. First, verify whether the SCTP traffic is legitimate signaling traffic (Diameter, SS7/M3UA) and check upstream network conditions for packet reordering or loss. If drops are persistent and affecting production traffic, consider whether SCTP inspection is required for your use case—disabling inspection will bypass the reorder queue mechanism entirely. For legitimate high-volume SCTP environments, ensure the firewall platform has sufficient CPU cores to support the expected number of concurrent streams with reordering. If drops occur during traffic spikes but subside quickly, the behavior is likely protective and benign. Contact Cisco TAC if drops persist and correlate with application-layer failures in SCTP-based services.

Syslogs:

None

----------------------------------------------------------------

sctp-shutack-chunk-unexpected

SCTP SHUTDOWN-ACK chunk received in invalid context

The firewall dropped an SCTP packet containing a SHUTDOWN-ACK chunk that violated protocol requirements. This occurs when a SHUTDOWN-ACK chunk is bundled with connection establishment chunks (INIT or INIT-ACK) in the same packet, which is prohibited by SCTP protocol rules. It can also occur if the SHUTDOWN-ACK arrives when no matching SCTP association exists, or when the association is not in a shutdown sequence (must be in SHUTDOWN-SENT, SHUTDOWN-RCVD, or SHUTDOWN-ACKSENT state). SCTP inspection enforces strict state machine validation to prevent malformed shutdown sequences that could disrupt legitimate associations or enable attacks.

Recommendation:

This drop typically indicates a protocol violation by one of the SCTP endpoints or a middlebox manipulating SCTP traffic. Verify that both SCTP endpoints are RFC 4960 compliant and not sending malformed packets. If the counter increments during normal operation, check whether a middlebox (load balancer, WAN optimizer) is improperly bundling SCTP chunks or injecting SHUTDOWN-ACK messages. Review SCTP inspection configuration with 'show service-policy' and consider temporarily disabling SCTP inspection with 'no inspect sctp' in the class-map to determine if inspection is causing legitimate traffic drops. If drops persist without inspection, the issue is likely with the SCTP endpoints themselves. Capture packets with 'capture' command to examine the exact chunk bundling and association state when drops occur.

Syslogs:

None

----------------------------------------------------------------

sctp-shutcomplete-chunk-unexpected

SCTP SHUTDOWN-COMPLETE chunk received without matching association

The firewall received an SCTP SHUTDOWN-COMPLETE chunk but could not match it to an existing SCTP association, or the association was not in the correct state to accept the shutdown completion. SHUTDOWN-COMPLETE is the final message in SCTP's graceful shutdown sequence and should only arrive when the firewall is expecting it (after sending a SHUTDOWN-ACK). This drop typically occurs when: the SCTP association has already been torn down or timed out before the SHUTDOWN-COMPLETE arrived; the verification tag in the packet does not match any known association; the packet is a retransmission arriving after the association was closed; or there is clock skew or asymmetric routing causing shutdown messages to arrive out of sequence. This is a normal condition during connection cleanup, especially in high-latency or lossy networks where shutdown messages may be delayed or retransmitted.

Recommendation:

This counter incrementing is usually benign and indicates normal SCTP connection teardown race conditions. No action is required if the counter increases occasionally. Investigate further if: the counter increments rapidly or continuously, indicating possible SCTP inspection issues or asymmetric routing; legitimate SCTP applications (such as Diameter or M3UA signaling) are failing to establish or maintain connections; or you observe corresponding application-layer failures. Check 'show sctp' to verify that SCTP associations are establishing and terminating normally. If SCTP inspection is enabled, verify that the inspection policy is not interfering with shutdown sequences. Review the SCTP timeout configuration if associations are being torn down prematurely. Capture packets if the drops correlate with application failures to determine whether shutdown messages are arriving out of order or with incorrect verification tags.

Syslogs:

None.

----------------------------------------------------------------

sctp-stream-id-invalid

SCTP DATA chunk references non-existent stream

The firewall received an SCTP DATA chunk that references a stream identifier that was not negotiated during association establishment. SCTP associations negotiate the number of inbound and outbound streams during the INIT/INIT-ACK handshake. Each DATA chunk must specify a stream ID within the agreed range (0 to N-1, where N is the negotiated stream count for that direction). This counter increments when a DATA chunk arrives with a stream ID equal to or greater than the negotiated maximum, which violates the SCTP protocol specification. The packet is dropped to prevent processing data on an undefined stream. This typically indicates a misconfigured SCTP endpoint, a protocol implementation bug in the peer application, or in rare cases, corrupted packets. SCTP multi-streaming is commonly used by signaling protocols such as Diameter (used in LTE/5G networks) and M3UA (SS7 over IP), where different message types are sent on separate streams to avoid head-of-line blocking.

Recommendation:

Verify the SCTP endpoint configuration on both sides of the connection. Check that the number of inbound and outbound streams configured on each peer matches the application requirements and that both endpoints agree on the stream counts during association setup. Use packet captures to examine the INIT and INIT-ACK chunks to confirm the negotiated stream parameters (Number of Inbound Streams and Number of Outbound Streams fields). If the peer is a telecom signaling application (Diameter, M3UA), consult the application vendor documentation for correct stream configuration. Occasional drops may indicate transient issues or retransmissions after a peer restart with different configuration. Sustained or high-rate drops suggest a persistent misconfiguration or a software defect in the peer SCTP stack. If the peer is a third-party application, contact the vendor. If drops occur under high connection rates or during failover events, this may indicate a timing issue in the peer's association state machine.

Syslogs:

None

----------------------------------------------------------------

security-failed

Early Security Checks Failed

This counter increments when the device detects and drops packets that fail basic security validation checks during initial processing. Three distinct security violations trigger this counter:

1. Multicast MAC/IP Address Mismatch: An IPv4 multicast packet arrives where the destination MAC address does not correspond to the multicast destination IP address. This check ensures multicast traffic is properly formed and prevents spoofing attempts. The check is bypassed in transparent firewall mode and on certain interface types (bridge virtual interfaces, tunnel interfaces, virtual access interfaces).

2. Teardrop Fragment Attack: The device receives an IPv4 or IPv6 fragment with characteristics of a teardrop attack—either a fragment with a very small offset (greater than 0 but less than 16 bytes), or overlapping fragments during reassembly. Teardrop attacks exploit vulnerabilities in fragment reassembly by crafting malicious overlapping fragments that can crash or compromise systems.

3. Legacy IP Audit Signature Match: The packet matches a configured IP audit (IDS) signature when the legacy intrusion detection feature is enabled. This applies only when an audit policy has been configured and the packet triggers one of the attack or informational signatures being monitored.

Recommendation:

Investigate the source and nature of the dropped traffic:

For multicast drops: Verify that multicast sources are sending properly formatted multicast packets. Check that the destination MAC address is correctly derived from the multicast IP address (the low-order 23 bits of the IP address should map to the MAC address 01:00:5E:xx:xx:xx for IPv4). If legitimate multicast traffic is being dropped, verify the firewall mode and interface configuration.

For teardrop fragment drops: This typically indicates a fragmentation attack or severely malformed traffic. Review syslog message 106020 for source/destination details. Legitimate traffic should never trigger this—fragments with offsets between 1-15 bytes or overlapping fragments are always malicious or severely broken. Identify and block the source if this persists. Note that in some software versions, syslog 106020 may be generated even when packets are not actually dropped (see defect CSCvx52491).

For IP audit signature matches: Review the specific signature that triggered (syslog 400xx series) using the command reference for IP audit signatures. Determine whether the match is a false positive or represents actual attack traffic. You can disable specific signatures using the 'ip audit signature' command if needed.

If drops are unexpected or affecting legitimate traffic, collect packet captures at the ingress interface and contact Cisco TAC with the capture, configuration, and output from 'show asp drop' and relevant syslogs.

Syslogs:

106020 (teardrop fragment), 400xx series (IP audit signature matches)

----------------------------------------------------------------

security-profile-not-matched

Security-profile not matched

Traffic was dropped because it arrived with a security profile identifier that does not match any security profile configured on the device. This counter is specific to the ASA 1000V virtual firewall platform when deployed with Cisco Nexus 1000V virtual switches in a Virtual Security Network (VSN) architecture. In this deployment model, the Nexus 1000V tags traffic with security profile identifiers based on port-profile configurations, and the ASA 1000V uses these identifiers to apply the correct security policies. This drop occurs when the identifier in the incoming traffic does not correspond to any security profile known to the ASA 1000V, indicating a configuration mismatch between the two devices.

Recommendation:

Verify that security profiles are consistently configured on both the Nexus 1000V and ASA 1000V. On the Nexus 1000V, use 'show port-profile' to confirm that each port-profile redirecting traffic to the ASA 1000V has an associated security-profile configured, and note the security-profile names. On the ASA 1000V, verify that matching security-profile names exist and are associated with the inside interface using the 'service-interface security-profile all <inside_interface_name>' command. Use 'show vsn port' on the Nexus 1000V and 'show vsn security-profile' on the ASA 1000V to verify that the security profile identifier values match between both devices. If identifiers are mismatched or missing, reconfigure the security profiles to ensure consistency. Note that this counter is only relevant for ASA 1000V deployments with Nexus 1000V integration and is relevant to ASA 1000V deployments using Nexus 1000V VSN integration.

Syslogs:

None.

----------------------------------------------------------------

security-profile-not-used

Security-profile not used

Traffic was received on the ASA 1000V (Virtual Security Gateway) without an associated security-profile. The ASA 1000V integrates with Nexus 1000V distributed virtual switches using vPath technology, where security-profiles define which traffic flows are redirected from the Nexus 1000V to the ASA 1000V for inspection. This counter increments when the ASA 1000V receives traffic that lacks the required security-profile association, indicating a configuration mismatch between the Nexus 1000V port-profile settings and the ASA 1000V service-interface configuration. This is specific to the ASA 1000V platform and does not apply to other ASA or FTD platforms.

Recommendation:

Verify the port-profile configuration on the Nexus 1000V includes a security-profile for each port-profile that redirects traffic to the ASA 1000V. Confirm that security-profile names match exactly between the Nexus 1000V and ASA 1000V configurations. On the ASA 1000V, verify security-profiles are bound to the inside interface using the service-interface command. Use show commands on both platforms to verify security-profile ID values match: check port-profile status on the Nexus 1000V and security-profile associations on the ASA 1000V. Note: The ASA 1000V platform reached end of sale in 2017 and end of support in 2022; consider migration to current virtual firewall platforms (ASAv or FTDv) if still running this legacy platform. This counter is relevant to ASA 1000V deployments using Nexus 1000V VSN integration.

Syslogs:

None.

----------------------------------------------------------------

send-ctm-error

Send to CTM returned error

This counter is obsolete in the appliance and should never increment.

Recommendation:

None

Syslogs:

None

----------------------------------------------------------------

service-interface-down

Service interface is down

ASA 1000V drops vPath-tagged traffic if the service interface has not been configured. This counter applies to ASA 1000V deployments using Nexus 1000V vPath.

Recommendation:

Ensure the service interface is configured. In ASDM mode, associate the security-profile interfaces with the inside interface using service-interface security-profile all <inside_interface_name>. Use show interface <inside_interface_name> to check the interface state. If it is administratively down, enable it with no shutdown; investigate any other cause of a down state. To check vPath service-node health and traffic handling, use show vservice node brief and show vservice connection on the Nexus 1000V.

Syslogs:

None

----------------------------------------------------------------

session-preproc

Blocked or blacklisted by the session preprocessor

This counter increments when the intrusion detection engine's session tracking component has blacklisted a connection and subsequent packets from that flow are being dropped. The session preprocessor maintains TCP and UDP connection state and can blacklist flows when it detects protocol violations, invalid state transitions, or other session-level anomalies. Once a flow is blacklisted, all remaining packets in that connection are dropped without further inspection. This is a performance optimization that prevents the inspection engine from repeatedly analyzing traffic from a connection that has already been determined to be malicious or invalid. Common triggers include TCP state machine violations, session hijacking attempts, or flows that violate configured session limits or timeouts.

Recommendation:

Use packet capture with trace enabled to identify which specific session condition triggered the blacklist decision. The trace output will show the inspection phase details and the specific reason the session preprocessor flagged the connection. Review intrusion policy settings related to session tracking, TCP normalization, and stream reassembly. If legitimate traffic is being dropped, verify that the application's TCP behavior conforms to RFC standards—non-standard implementations may trigger session tracking violations. Check for asymmetric routing, which can cause the session preprocessor to see incomplete connection state. For high-volume environments, verify that session limits and memory settings are appropriately sized. If drops persist for legitimate traffic, consider adjusting the intrusion policy's session preprocessor settings or creating exceptions for the affected traffic patterns.

Syslogs:

None

----------------------------------------------------------------

session-string

Snort session debug information

This counter is incremented when the packet tracer captures session-level debug information from the inspection engine. It appears in packet tracer output when detailed session tracking is enabled and does not represent an actual packet drop. The counter serves as an internal marker for diagnostic data collection during troubleshooting sessions.

Recommendation:

This counter is informational only and does not indicate a problem. It increments when using packet tracer commands with inspection engine debug options enabled. No action is required. If you see this counter incrementing without actively running packet tracer diagnostics, contact Cisco TAC for assistance.

Syslogs:

None.

----------------------------------------------------------------

sfr-bad-handle-received

Flow handle mismatch detected in packet returned from FirePOWER module

This counter increments when the ASA receives a packet back from the FirePOWER (SFR) service module with a flow identifier that does not match the identifier originally assigned to that flow. When traffic is redirected to the SFR module for inspection, the ASA and SFR module maintain synchronized flow state using unique flow handles. If the SFR module returns a packet with a different handle than expected for an existing flow, it indicates a serious state synchronization problem between the ASA dataplane and the SFR module. The ASA drops the packet and tears down the affected flow to prevent potential security issues from the state mismatch. This condition typically occurs on ASA 5500-X series platforms (5506-X, 5508-X, 5516-X) with an installed SFR hardware module when there is a communication failure or state desynchronization between the ASA and the module.

Recommendation:

Check for syslog message 434003, which identifies the specific flow that triggered this drop. Verify the health of the SFR module using 'show module' and check for dataplane communication errors with 'show sfr'. Look for messages indicating data channel failures (323006) or module communication issues. If the SFR module is configured in monitor-only mode and you see repeated occurrences, review known issues related to dataplane communication in that mode. If drops persist, collect 'show tech-support' output from both the ASA and SFR module, and contact Cisco TAC, as this indicates a state synchronization failure that may require module reload or software upgrade.

Syslogs:

434003

----------------------------------------------------------------

sfr-bad-tlv-received

Packet returned from FirePOWER module with invalid metadata

The ASA dropped a packet that was returned from the FirePOWER Services (SFR) module because the metadata attached to the packet failed validation. When the ASA redirects packets to the SFR module for advanced inspection, the module returns them with Type-Length-Value (TLV) metadata containing policy decisions and connection tracking information. This counter increments when the returned metadata has an unrecognized type or incorrect length field. This typically indicates a software issue in the communication protocol between the ASA dataplane and the SFR module, or corruption during backplane transmission. The drop occurs on ASA 5500-X series platforms (5506-X, 5508-X, 5516-X) that have an integrated FirePOWER Services module installed and active.

Recommendation:

This drop usually indicates a software defect in the ASA-to-SFR communication layer. Check the SFR module status with 'show module' and review any error messages or alerts on both the ASA and the SFR module using 'show module sfr log'. If the SFR module is operational but this counter is incrementing, collect the output of 'show asp drop' and 'show module' and contact Cisco TAC. In rare cases, enabling jumbo-frame reservation on the ASA may resolve issues related to oversized metadata frames. If the SFR module is unresponsive or in a failed state, reload the module with 'hw-module module 1 reload' after verifying there are no active critical inspections.

Syslogs:

None directly associated. Check for SFR module status messages (747xxx series) and IPS/FirePOWER service messages (420xxx series).

----------------------------------------------------------------

sfr-fail-close

SFR module unavailable with fail-close policy

This counter increments when packets are dropped because they match a service policy that redirects traffic to the FirePOWER (SFR) module for inspection, but the SFR module's data plane is not operational and the policy is configured with the fail-close option. Fail-close mode prioritizes security by blocking traffic when the inspection service is unavailable, rather than allowing uninspected traffic to pass. This drop typically occurs during SFR module boot, reload, software upgrade, or hardware failure. On ASA platforms with SFR modules (such as ASA 5506/5508/5516 or ASA 5585-X with SSP cards), the module may take several minutes to become operational after a restart. In high-availability or cluster deployments, the behavior depends on whether one or both units' SFR modules are down; if both are unavailable, all redirected traffic is dropped.

Recommendation:

Check the operational status of the SFR module using 'show module' or 'show module sfr details'. If the module shows 'Up' but the data plane status is 'Down', the module may be booting or experiencing a software issue—wait for it to complete initialization or reload the module. If the module is consistently failing, investigate hardware issues, software compatibility between ASA and SFR versions, or resource exhaustion on the module. If fail-close behavior is causing unacceptable service disruption during module outages, consider changing the service policy to fail-open mode (which allows traffic to bypass inspection when the module is unavailable) by removing the 'sfr fail-close' option from the policy configuration. In high-availability deployments, verify that at least one unit's SFR module is operational to maintain service continuity. Review syslog messages 434001 or 420001 for details on which traffic is being dropped.

Syslogs:

434001, 420001

----------------------------------------------------------------

sfr-ha-request

SFR module HA replication dropped

The appliance received a high availability replication message from the FirePOWER Services (SFR) module but could not process it. The SFR module sends these messages to synchronize its internal state with the ASA high availability status. Drops occur when the ASA cannot forward the message to the peer unit due to local HA state conditions: the unit is not active, the stateful failover link is down, internal message queues are full, or the message exceeds the maximum transfer size. Transient drops are normal during HA state transitions—when a standby unit is joining the pair, during failover events, or immediately after the stateful link recovers. This counter applies only to ASA platforms with an integrated FirePOWER Services module operating in a high availability pair.

Recommendation:

Check the current high availability state with 'show failover' and verify both units show 'Active' or 'Standby Ready' status. If the counter increments only during known HA events (unit reloads, failover tests, or stateful link flaps), the drops are expected and require no action. If the counter increases steadily during normal operation, verify the stateful failover link is up and stable, confirm both ASA units and their SFR modules are running compatible software versions, and check for resource exhaustion (memory, CPU) on the active unit. Persistent drops with a stable HA pair indicate a synchronization problem between the ASA HA subsystem and the SFR module; collect the output of 'show failover', 'show module', and 'show asp drop' from both units and contact Cisco TAC.

Syslogs:

None.

----------------------------------------------------------------

sfr-invalid-encap

SFR High Availability Message Header Invalid

This counter increments when the security appliance receives a malformed high availability synchronization message from the FirePOWER (SFR) module and drops it. The drop occurs when the internal backplane communication protocol detects header validation failures in messages exchanged between FirePOWER modules on high availability peer units. Specific validation failures include: incorrect IP type field (non-IPv4), mismatch between the declared message length and actual packet size, or unrecognized message types during state or configuration synchronization. This counter applies only to ASA 5500-X series platforms with installed FirePOWER (SFR) service modules operating in a high availability configuration.

Recommendation:

This counter typically indicates a software defect or corruption in the FirePOWER module's high availability synchronization logic. If you observe this counter incrementing, verify that both high availability peer units are running identical software versions on both the ASA and FirePOWER module. Check the health of the high availability link and verify that the FirePOWER modules on both units are operational using 'show module' and 'show module sfr details'. Review FirePOWER module logs for any errors related to high availability synchronization. If the counter continues to increment and high availability synchronization is impaired, reload the FirePOWER module on the affected unit using 'sw-module module sfr reload'. If the issue persists after ensuring version consistency and module health, contact Cisco TAC with the output of 'show asp drop' and 'show module' from both high availability peers.

Syslogs:

None.

----------------------------------------------------------------

sfr-malformed-packet

Malformed Packet from FirePOWER Services Module

This counter increments when the ASA receives a packet back from the FirePOWER Services (SFR) module over the internal backplane that fails header validation checks. The ASA and SFR module communicate using an internal protocol that encapsulates inspected packets with metadata. When a returning packet has corrupted or invalid header fields—such as an invalid IP type indicator, malformed action flags, inconsistent layer-3 offset values, or incorrect length fields—the ASA cannot safely process the packet and drops it. This condition typically indicates a software defect in the SFR module's packet processing or a hardware issue affecting the backplane communication channel. It only occurs on ASA platforms with an installed SFR module when traffic redirection to the module is configured.

Recommendation:

This drop reason indicates an abnormal condition that should not occur during normal operation. Check the SFR module status and health using 'show module' and 'show sfr' commands. Review syslogs from both the ASA and the SFR module for errors related to packet processing or module communication. If the counter is incrementing, verify that both the ASA and SFR module are running compatible software versions. Consider reloading the SFR module using 'hw-module module 1 reload' if the issue persists. If drops continue after a module reload, collect troubleshooting data from both the ASA and SFR module and contact Cisco TAC, as this may indicate a software defect or hardware failure affecting the backplane interface.

Syslogs:

434004, 434007

----------------------------------------------------------------

sfr-no-flow

SFR redirection removed for active connection

This counter increments when a packet arrives on an existing connection that was previously configured for FirePOWER (SFR) module inspection, but the SFR redirection policy has been removed or is no longer available. This typically occurs when you remove or modify a service policy containing an 'sfr' action while connections matching that policy are still active. The packet is dropped because the system cannot redirect it to the SFR module as originally configured for the flow. This situation is most common on ASA 5500-X series platforms with an installed SFR module (such as ASA5585-SSP or ASA5515-X with FirePOWER Services).

Recommendation:

This drop is expected during configuration changes and does not indicate a problem. Active connections will be dropped when you remove SFR redirection policies; new connections will follow the updated policy. To minimize disruption: (1) Plan service policy changes during maintenance windows when possible, (2) Use 'clear conn' to proactively tear down affected connections after policy changes if immediate cleanup is desired, (3) Verify the SFR module is operational with 'show module' and 'show service-policy' before making policy changes. If you see this counter incrementing without recent configuration changes, verify that the SFR module has not failed or been removed - check 'show module' for module status and review any syslog messages related to SFR module health (434xxx series messages).

Syslogs:

434001 (SFR card not up and fail-close mode)

----------------------------------------------------------------

sfr-request

FirePOWER Services Module requested drop

This counter increments when the FirePOWER Services module (SFR) or Snort inspection engine returns a verdict instructing the firewall to drop a packet or terminate a connection. Traffic redirected to the module for deep packet inspection may be blocked based on intrusion prevention signatures, file policies, access control rules, or malware detection. The module communicates its enforcement decision back to the firewall datapath, which then drops the packet and logs this counter. Common scenarios include: intrusion prevention system (IPS) signature matches that trigger block actions, file type or malware blocking policies, access control rules configured to deny specific applications or URLs, and SSL decryption policies that inspect and block encrypted traffic. This counter reflects normal operation when security policies are actively enforcing blocks—it indicates the module is successfully protecting the network by preventing malicious or policy-violating traffic from reaching its destination.

Recommendation:

Review the FirePOWER Services module event logs and intrusion alerts to identify which security policy triggered the drop. On ASA with FirePOWER Services, use the module's management interface or FMC to examine connection events, intrusion events, and file/malware events that correlate with the timestamp of the drops. Check syslog message 434002 for details about the blocked flows, including source and destination addresses, ports, and protocol. If drops are unexpected, verify that access control policies, intrusion policies, and file policies are configured correctly and not overly restrictive. For SSL-related drops during decryption and re-encryption operations, note that a separate counter (sfr-request-ssl-decrypt) tracks SSL decryption drops specifically. If legitimate traffic is being blocked, adjust the security policy rules, add exceptions for trusted sources, or tune intrusion prevention signatures to reduce false positives. This counter incrementing is expected and normal when the module is actively enforcing security policies—investigate only if business-critical applications are being blocked unintentionally.

Syslogs:

434002

----------------------------------------------------------------

sfr-request-ssl-decrypt

FirePOWER Services SSL decryption drop

This counter increments when the FirePOWER Services module drops packets during SSL/TLS decryption and inspection operations. When an SSL decryption policy is configured on ASA with FirePOWER Services, encrypted traffic is redirected to the module for decryption, deep packet inspection, and policy enforcement. The module may drop packets based on intrusion prevention rules, file policies, malware detection, or other security policies applied to the decrypted content. This counter tracks drops specifically requested by the module during SSL decryption workflows and is distinct from other module-requested drops. These drops are expected behavior when SSL decryption policies are active and enforcing security controls on encrypted traffic.

Recommendation:

This counter incrementing is normal when SSL decryption policies are deployed and actively inspecting encrypted traffic. Review the FirePOWER Services event logs and intrusion events to identify which security policies triggered the drops and whether the blocked traffic represents legitimate threats or requires policy tuning. If the counter increments unexpectedly when no SSL decryption policy is configured, verify the module configuration and health. High drop rates may indicate overly restrictive policies, false positives, or legitimate attack traffic being blocked. Use the module's event viewer to correlate drops with specific rules, signatures, or file verdicts to determine if policy adjustments are needed.

Syslogs:

None

----------------------------------------------------------------

sfr-rx-monitor-only

SFR packet received in monitor-only mode

The firewall received a packet back from the SFR (Sourcefire) module through the inline processing path, but the associated traffic flow is configured for monitor-only (inline-tap) mode. In monitor-only mode, packets are copied to SFR for passive inspection and the original packets continue forwarding immediately without waiting for an SFR verdict. Packets should not return through the normal inline receive path in this mode. This counter indicates a configuration inconsistency or internal state mismatch between the firewall and the SFR module regarding the inspection mode for the flow. This condition is most commonly seen in multi-context deployments where different contexts have conflicting SFR redirection policies—some configured for inline mode (sfr fail-open or sfr fail-close) and others for monitor-only mode (sfr fail-open monitor-only or sfr fail-close monitor-only).

Recommendation:

Verify that SFR redirection configuration is consistent across all contexts if running in multi-context mode. Use 'show service-policy' to check the configured SFR mode on each interface. If mixing inline and monitor-only modes across contexts, upgrade to a release that includes the fix for CSCwb90074, which adds validation to prevent this misconfiguration. If the issue persists on a single-context deployment or after ensuring configuration consistency, contact Cisco TAC with the output of 'show asp drop' and 'show service-policy' for further analysis, as this may indicate an internal state synchronization issue between the firewall data plane and the SFR module.

Syslogs:

None.

----------------------------------------------------------------

shunned

Packet from shunned host

A packet was dropped because its source IP address matches an entry in the shun database. Shuns block all traffic from a specific host on the interface where the shun is applied. Shuns can be added in three ways: manually via the 'shun' command, automatically by the threat detection scanning-threat feature when port scans or host sweeps are detected, or automatically by threat detection services (such as remote access VPN authentication failure protection) when attack thresholds are exceeded. When a shun is installed, the device also tears down any existing connections from that host. This counter increments for every packet received from a shunned source address, confirming that the block is working as intended.

Recommendation:

This is normal operation when shuns are in use. Review the active shun list with 'show shun' to identify which hosts are blocked and why (manual, scanning-threat, or service-based). Check syslog message 401002 or 733102 to see when and why each host was shunned. If a host was shunned by threat detection and should no longer be blocked, remove it with 'clear shun <ip-address>' (for manual shuns) or 'clear threat-detection shun' (for scanning-threat shuns) or 'clear threat-detection service shun' (for service-based shuns). If legitimate hosts are being shunned by threat detection, adjust the rate thresholds or add the hosts to the shun exception list using 'threat-detection service shun except'. If shuns are not intentionally configured and this counter is incrementing, verify that threat detection features are not inadvertently enabled.

Syslogs:

401002, 401004, 733102, 733103

----------------------------------------------------------------

si

Blocked by Security Intelligence policy

Traffic was blocked because the source IP, destination IP, URL, or DNS domain matched a Security Intelligence blacklist configured in your threat defense policy. Security Intelligence provides reputation-based filtering that evaluates connections against threat intelligence feeds before access control rules are processed. This counter increments when a connection is denied due to a match against IP reputation lists, DNS blacklists, or URL category feeds configured in the Security Intelligence policy. This is expected behavior when Security Intelligence is actively protecting your network from known malicious sources or destinations.

Recommendation:

Review your Security Intelligence policy in Firepower Management Center to confirm the block was intentional. Use packet tracer or enable Snort tracing to identify which specific blacklist entry (IP address, URL, or DNS domain) triggered the block. If legitimate traffic is being blocked, adjust your Security Intelligence whitelist to exclude trusted sources or destinations. Check connection events in the FMC event viewer for details about blocked connections, including the matched threat intelligence feed. If the block is unexpected, verify that your threat intelligence feeds are up to date and review recent policy changes. This counter is normal during active threat prevention and does not indicate a system error.

Syslogs:

None.

----------------------------------------------------------------

smb

Blocked by the DCE/RPC SMB inspection engine

This counter increments when the deep packet inspection engine drops an SMB (Server Message Block) packet based on the DCE/RPC SMB preprocessor's analysis. The inspection engine examines SMB protocol traffic (versions 1, 2, and 3) for protocol violations, policy enforcement, and security threats. Drops occur when the inspection engine detects malformed SMB commands, invalid session state transitions (such as multiple negotiations on the same session), unsupported or policy-restricted commands (for example, certain raw read/write commands under IPC trees when inspecting Samba or Windows Vista+ targets), missing or invalid user/tree identifiers, or when file inspection policies block file transfers over SMB. This counter is specific to FTD platforms running Snort 3 inspection with DCE/RPC SMB inspection enabled in the Network Analysis Policy.

Recommendation:

Enable packet capture with trace to see the detailed Snort verdict reason. Use 'capture asp-drop smb trace' to collect packets and examine the Snort inspection output in the trace data. Review the Network Analysis Policy DCE/RPC configuration to verify that SMB inspection settings (policy type, file inspection depth, command restrictions) match your environment's requirements. Check Connection Events in FMC to identify which specific SMB flows are being dropped and correlate with any intrusion events or file policy blocks. If legitimate SMB traffic is being dropped, consider adjusting the DCE/RPC server policy fingerprint (Windows XP, Vista, 2008, Samba variants) to match your actual server operating systems, or create a prefilter rule to fastpath trusted SMB traffic. If drops correlate with file transfers, review file policy settings and inspection depth limits. Contact TAC if drops occur without corresponding intrusion events or file blocks, as this may indicate a protocol parsing issue.

Syslogs:

None.

----------------------------------------------------------------

snort-blacklist

Packet dropped because flow is blacklisted by Security Intelligence

This counter increments when a packet arrives on a connection that has been blacklisted by the Snort inspection engine. A blacklist verdict is issued by Snort's reputation preprocessor (Security Intelligence) when the source or destination IP address, URL, or DNS query matches a threat intelligence feed configured in your intrusion or access control policy. Once a flow receives a blacklist verdict, all subsequent packets on that connection are dropped and counted here, even if the initial packet that triggered the reputation match has already been handled. This is distinct from per-packet block verdicts; blacklisting marks the entire flow for the duration of the connection.

Recommendation:

Review your Security Intelligence configuration and threat intelligence feeds to determine which IP address, URL, or DNS domain triggered the blacklist. Use 'show asp inspect-dp snort' to verify Snort instance health and 'packet-tracer' to see the specific reputation match. If legitimate traffic is being blacklisted, adjust your Security Intelligence whitelist or modify the threat feed subscriptions in your intrusion policy. If the blacklist is intentional (blocking known malicious sources), this counter reflects normal security policy enforcement and no action is needed. For unexpected blacklisting of internal or trusted hosts, verify that your Security Intelligence configuration excludes trusted networks.

Syslogs:

None directly associated. For reputation-based blocks, see syslog 338005 and 338006 (Dynamic Filter dropped blacklisted traffic) if using the legacy Botnet Traffic Filter feature.

----------------------------------------------------------------

snort-blist-full

Snort inspection flow packet queue limit exceeded

This counter increments when a flow undergoing inspection has too many packets queued in the data path waiting for in-order delivery. When the inspection engine marks a flow as fast-forward (meaning initial inspection is complete and the flow can bypass further deep inspection), the data path must still maintain packet order. If some packets are still being processed by the inspection engine while new packets arrive, the new packets are temporarily queued per-flow. When this per-flow queue exceeds its limit, additional packets are dropped and the affected TCP connection is terminated with reset packets sent to both client and server. This protects system resources from being exhausted by flows with excessive queuing requirements. The condition typically occurs during high-throughput scenarios where the inspection engine cannot keep pace with packet arrival rates, or when out-of-order packet arrival causes temporary queuing delays.

Recommendation:

This drop indicates the inspection engine is experiencing delays processing packets for specific flows. First, verify inspection engine health using 'show snort' and check for Automatic Application Bypass events or high latency. Review 'show asp drop' for other inspection-related drops that may indicate broader performance issues. If drops are persistent, consider: (1) reviewing and optimizing intrusion policies to reduce inspection overhead, (2) using prefilter rules to bypass inspection for trusted or low-risk traffic, (3) verifying the device is not CPU-constrained during peak traffic periods. For isolated occurrences during traffic bursts, the drops may be expected behavior protecting system stability. If drops correlate with application failures or connection resets, collect a troubleshooting bundle and contact Cisco TAC, as this may indicate inspection engine performance degradation or resource exhaustion.

Syslogs:

None

----------------------------------------------------------------

snort-blist-full-failopen

Snort fail-open per-flow queue limit exceeded

This counter increments when the threat defense inspection engine is operating in fail-open mode and a flow's packet queue has reached its maximum capacity. Fail-open mode activates when the inspection engine becomes busy or unavailable, and the system is configured to allow traffic to continue flowing rather than dropping it. To prevent out-of-order packet delivery during fail-open, packets are temporarily queued on a per-flow basis. When a flow's queue reaches the configured limit (default is typically a small number of packets), additional packets for that flow are dropped and the connection is terminated with TCP reset packets sent to both endpoints. This protects system resources when the inspection engine cannot keep up with traffic volume.

Recommendation:

This drop typically indicates the inspection engine is overloaded or experiencing performance issues. First, check the health of the inspection engine using 'show asp inspect-dp snort' to verify if instances are busy or down. Review 'show asp inspect-dp snort queues' to identify queue backpressure. If the inspection engine is consistently busy, consider: (1) reviewing and optimizing intrusion policies to reduce inspection load, (2) evaluating whether traffic volume exceeds platform capacity, (3) checking for resource constraints (CPU, memory) on the device. If drops are isolated to specific flows during temporary inspection engine unavailability, they may be expected behavior. Persistent drops indicate the inspection engine cannot process traffic at the required rate. The per-flow queue limit is tunable via debug commands but increasing it only delays the problem—address the root cause of inspection engine overload instead.

Syslogs:

None

----------------------------------------------------------------

snort-block

Traffic blocked by intrusion prevention rule

This counter increments when the intrusion prevention system (IPS) inspection engine determines that a packet should be blocked based on a matching intrusion rule configured with a Block or Drop action. The packet is sent to the inspection engine for deep packet inspection, and when the engine identifies a signature match for a rule set to block traffic, it returns a block verdict to the datapath, which then drops the packet and increments this counter. This is normal and expected behavior when intrusion prevention policies are actively blocking malicious or policy-violating traffic. The counter reflects successful enforcement of your intrusion prevention rules.

Recommendation:

Review the intrusion events in the management center (FMC) or device manager (FDM) to identify which intrusion rule triggered the block. Verify that the blocking rule is intentional and correctly configured for your security policy. If legitimate traffic is being blocked, adjust the intrusion policy by changing the rule action from Block to Alert (detection-only mode), disabling the specific rule, or creating an exception. Note that when an intrusion policy is set to Detection mode (IDS), rules should generate alerts only; if traffic is still being blocked in Detection mode, verify that individual rules are not overridden with Block actions. Use the connection events and intrusion events logs to correlate blocked traffic with specific signatures. If the blocks are expected and part of your security posture, no action is required—this counter confirms your IPS is actively protecting the network.

Syslogs:

420002

----------------------------------------------------------------

snort-busy

Packet dropped because the inspection engine is busy and cannot process traffic

This counter increments when packets are dropped because the inspection engine cannot process them quickly enough due to resource constraints, high traffic load, or internal queueing limits. The behavior depends on the interface type and configuration:

• Inline-tap and passive interfaces: Packets are always dropped when the inspection engine is busy, regardless of configuration.

• Inline non-tap and routed interfaces: Packets are dropped unless fail-open busy mode is configured on the inline-set or interface, in which case traffic bypasses inspection instead.

This drop typically occurs during traffic spikes, sustained high connection rates, or when the inspection engine is under-resourced for the traffic volume. Once a connection is marked for fail-open bypass, subsequent packets on that flow will not be sent for inspection even after the inspection engine recovers.

Recommendation:

1. Check inspection engine statistics using 'show snort statistics' to verify if the engine is actually overloaded (look for high packet counts, queue depths, or CPU utilization).

2. For inline-tap or passive interfaces, these drops are expected when the inspection engine cannot keep up—consider reducing traffic volume or increasing inspection resources.

3. For inline non-tap or routed interfaces without fail-open configured, evaluate whether to enable fail-open busy mode on the inline-set to allow traffic to bypass inspection during overload conditions rather than being dropped. This trades security inspection for availability.

4. If drops occur when the inspection engine does not appear busy (low CPU, normal statistics), this may indicate an internal resource issue or queueing problem—collect diagnostics and contact Cisco TAC.

5. For sustained high drop rates, investigate whether the platform is appropriately sized for the traffic volume and inspection policy complexity.

Syslogs:

None.

----------------------------------------------------------------

snort-busy-in-fp

Packet dropped because inspection engine is overloaded during TCP full-proxy operation

This counter increments when the inspection engine (Snort) is overloaded and cannot process packets for a connection that is operating in TCP full-proxy mode. Full-proxy mode is activated when the inspection engine needs to terminate and inspect the TCP connection payload, typically for TLS/SSL decryption or deep packet inspection policies. When the inspection engine becomes busy during full-proxy operation, packets are queued up to a per-flow limit. Once that limit is exceeded, packets are dropped to prevent memory exhaustion. This drop occurs only when fail-open for Snort busy is not configured on the interface or inline set, or when the connection has already exceeded its queuing threshold. TCP FIN and RST packets are exempt from this drop to allow connections to terminate gracefully even when the inspection engine is overloaded.

Recommendation:

Check the inspection engine load using 'show snort' and 'show snort statistics'. High CPU usage or packet processing delays indicate the inspection engine is overwhelmed. Review your access control and intrusion policies to identify resource-intensive rules or features. If TLS/SSL decryption is enabled, verify that decryption policies are scoped appropriately—decrypting all traffic can significantly increase inspection load. Consider enabling fail-open for Snort busy on inline sets or routed interfaces to allow traffic to bypass inspection during overload conditions, though this reduces security visibility. For inline-tap and passive interfaces, fail-open is not available and drops are expected during overload. If drops persist, evaluate whether the platform has sufficient resources for the configured policies and traffic volume, or consider policy optimization to reduce inspection overhead.

Syslogs:

852001 (when connection transitions to full-proxy mode)

----------------------------------------------------------------

snort-busy-inline-flow

Packet dropped because inspection engine is busy on inline-tap or passive interface

This counter increments when packets are dropped because the threat inspection engine is overloaded and cannot process additional traffic, and the ingress interface is configured in inline-tap mode or passive (monitor-only) mode. When the inspection engine is busy—typically due to high traffic volume, complex rule evaluation, or resource constraints—the system must decide whether to drop packets or allow them to pass uninspected. For inline-tap and passive interfaces, the design always drops packets during busy conditions, regardless of fail-open configuration. This behavior differs from inline (non-tap) and routed interfaces, where the fail-open setting for busy conditions determines whether packets are dropped or bypassed. The busy condition can occur when inspection queues are full, CPU resources are exhausted, or the inspection engine is temporarily unable to keep pace with the incoming packet rate.

Recommendation:

First, verify the interface mode with 'show inline-set' or 'show interface' to confirm the interface is configured as inline-tap or passive. Check inspection engine load with 'show snort' and 'show snort statistics' to identify busy conditions and review the 'Packets bypassed (Snort Busy)' counter. Use 'show snort cpu' to assess per-instance CPU utilization—sustained high utilization (above 80-90%) indicates the inspection engine is overloaded. Review 'show asp drop' for other inspection-related drops that may indicate systemic overload. If drops are occurring during expected traffic peaks, consider tuning the inspection policy to reduce complexity (fewer rules, optimized preprocessors), increasing hardware resources, or distributing load across multiple devices. For inline-tap interfaces, evaluate whether the tap mode is necessary—if fail-open behavior is desired during busy conditions, reconfigure the interface as inline (non-tap) and enable the fail-open busy setting. For passive interfaces used for monitoring, these drops do not affect forwarded traffic but indicate incomplete visibility during high-load periods. If drops persist during normal traffic loads, collect a troubleshooting bundle and contact Cisco TAC, as this may indicate a resource exhaustion issue or inspection engine malfunction.

Syslogs:

None.

----------------------------------------------------------------

snort-busy-no-app-info

Packet dropped due to Snort busy with missing application flow information

This counter increments when the threat defense engine (Snort) is busy processing traffic and the firewall cannot locate the internal application flow tracking structure needed to handle the packet. This is a specific subset of Snort-busy conditions where the flow metadata required to apply fail-open policies or queue the packet is unavailable. The packet is dropped immediately because the system lacks the information needed to determine whether fail-open should apply or how to queue the packet for later inspection. This typically occurs during periods of high inspection load when Snort instances are overloaded and internal flow tracking structures become inconsistent or unavailable. On FTD platforms, this may indicate that the communication channel between the data plane and Snort inspection instances (PDTS queues) is experiencing resource exhaustion or that internal block management counters have reached limits.

Recommendation:

Check Snort instance health and load with 'show asp inspect-dp snort' to identify overloaded instances or stuck queues. Look for instances showing 100% CPU utilization or TX queue saturation. Review 'show asp inspect-dp snort queue-exhaustion' for queue saturation events. If drops persist, examine 'show blocks' output for block pool exhaustion (particularly 9K blocks on high-throughput platforms). For inline-set deployments experiencing sustained drops, consider enabling Snort fail-open for busy conditions to allow traffic to bypass inspection during overload rather than dropping. If drops occur without corresponding high Snort CPU or queue exhaustion, this may indicate an internal flow tracking issue requiring a reload or software upgrade. Collect a troubleshooting bundle and contact Cisco TAC if drops continue after addressing Snort load issues.

Syslogs:

None.

----------------------------------------------------------------

snort-busy-not-fp

Packet dropped because Snort inspection engine is busy (non-proxy mode)

This counter increments when the Snort inspection engine is overloaded and unable to process packets, and the connection is not using full TCP proxy mode. The drop occurs when fail-open is not configured or not applicable for the interface type. Snort operates in lightweight inspection mode for most traffic, switching to full TCP proxy mode only when deep payload inspection is required (such as SSL/TLS decryption or certain application-layer protocols). When Snort becomes busy—typically during traffic spikes or when processing large flows—the system must decide whether to drop or bypass packets. For inline-tap and passive interfaces, packets are always dropped when Snort is busy. For inline (non-tap) and routed interfaces, packets are dropped unless the 'snort fail-open busy' option is configured on the inline-set or interface, which would allow traffic to bypass inspection instead. This drop commonly occurs when internal buffer resources are depleted (typically when block usage exceeds 80%), preventing the datapath from queuing packets for Snort inspection.

Recommendation:

Check Snort resource utilization with 'show asp inspect-dp snort' to identify overloaded instances. Review traffic patterns during the time of drops to identify traffic spikes or large flows (elephant flows). If drops are impacting critical traffic, consider: (1) enabling 'snort fail-open busy' on the inline-set or interface to allow traffic bypass during overload conditions instead of dropping, (2) using prefilter rules to fast-path high-volume or trusted traffic that does not require deep inspection, reducing load on Snort, or (3) reviewing access control and intrusion policies to ensure they are optimally tuned and not performing unnecessary inspection. Monitor system memory and buffer utilization with 'show blocks' and 'show memory' to identify resource constraints. If drops persist despite adequate resources, contact Cisco TAC for assistance in analyzing Snort performance and tuning inspection policies.

Syslogs:

None

----------------------------------------------------------------

snort-detain

Packet detained for TLS inspection verdict

This counter increments when a packet marked for detention reaches TCP normalization during TLS decryption inspection. Packet detention is a normal flow-control mechanism used when SSL/TLS decrypt policies (decrypt-resign or decrypt-known-key) are applied. During TLS decryption, the device decrypts traffic, holds (detains) packets in internal queues while waiting for the inspection engine to analyze the decrypted content and return a verdict, then releases the packets based on that verdict. The detained packets are not lost—they are temporarily held to maintain proper sequencing while inspection completes. This counter reflects packets in the detained state that have been accounted for by the normalization layer.

Recommendation:

This counter is informational and indicates normal operation of TLS decryption with inspection. The counter will increment on connections subject to SSL/TLS decrypt policies where traffic is being inspected by Snort. No action is required unless you observe connection failures or performance issues on TLS-inspected flows. If TLS connections are timing out or experiencing high latency, verify that the inspection engine is healthy (check 'show snort' status) and that the device is not overloaded. High values are expected on systems with active TLS decryption policies and significant encrypted traffic volume.

Syslogs:

None.

----------------------------------------------------------------

snort-down

Packet dropped because the Snort inspection engine is unavailable

This counter increments when a packet requiring deep packet inspection is dropped because the Snort inspection process is not running or has been suspended. The Snort engine may be down due to a crash, restart, manual shutdown, or Automatic Application Bypass (AAB) triggering a forced restart when Snort becomes unresponsive. The drop behavior depends on the interface type and fail-open configuration. On inline-tap and passive interfaces, packets are always dropped when Snort is unavailable. On inline (non-tap), routed, and transparent firewall interfaces, packets are dropped unless the interface or inline set is configured with fail-open-down mode, which allows traffic to bypass inspection and continue forwarding. Once a flow is marked as fail-opened, it continues to bypass Snort even after the inspection engine recovers. This counter is distinct from the snort-busy counter, which tracks drops when Snort is running but overloaded.

Recommendation:

Check the operational status of the Snort inspection engine using 'show snort status' and review 'show snort statistics' for the 'Packets bypassed (Snort Down)' counter to confirm whether fail-open is active. Look for syslog messages %ASA-3-850001 or %ASA-3-850002, which indicate Automatic Application Bypass events that may have forced a Snort restart. If Snort is repeatedly crashing or being restarted by AAB, collect a troubleshooting bundle and review Snort core files to identify the root cause. If drops are occurring on inline interfaces without fail-open configured and traffic disruption is unacceptable, consider enabling fail-open-down mode on the inline set using 'snort fail-open-down' under the inline-set configuration, or globally using 'configure snort preserve-connection' to allow existing connections to survive Snort outages. If this counter increments during a planned Snort restart or upgrade, it is expected behavior. For persistent issues, contact Cisco TAC with the troubleshooting bundle and any Snort core files.

Syslogs:

%ASA-3-850001, %ASA-3-850002

----------------------------------------------------------------

snort-down-in-fp

Packet dropped because inspection engine is unavailable during full TCP proxy operation

This counter increments when packets are dropped because the inspection engine is unavailable and the connection is operating in full TCP proxy mode. Full proxy mode is activated for deep packet inspection scenarios such as TLS decryption or certain application-layer inspections. When the inspection engine becomes unavailable, packets on these connections cannot be forwarded for inspection. The drop behavior depends on the interface type and fail-open configuration: inline-tap and passive interfaces always drop packets when the inspection engine is down; inline and routed interfaces drop packets unless fail-open-down is configured. This counter specifically tracks drops for connections with pending TCP segments awaiting inspection engine processing.

Recommendation:

Check the inspection engine status and resource utilization. Review interface configuration to determine if fail-open-down behavior is appropriate for your deployment. For inline-tap and passive interfaces, drops are expected when the inspection engine is unavailable. For inline and routed interfaces, consider configuring fail-open-down if business continuity during inspection engine outages is required. If the inspection engine is frequently unavailable, investigate resource constraints (CPU, memory), configuration issues, or potential software defects. Use inspection engine statistics and health monitoring commands to identify the root cause of unavailability. For persistent issues, collect diagnostic data and contact Cisco TAC.

Syslogs:

None.

----------------------------------------------------------------

snort-down-inline-flow

Packet dropped because Snort inspection engine is unavailable on inline-tap or passive interface

This counter increments when packets are dropped because the Snort inspection engine is unavailable (down, restarting, or crashed) and the traffic arrived on an inline-tap or passive interface. Unlike routed or standard inline interfaces that can be configured with fail-open policies to allow traffic when Snort is unavailable, inline-tap and passive interfaces always drop packets when Snort cannot inspect them. This is by design because these interface types are intended for monitoring or tap scenarios where uninspected traffic should not be forwarded. Common causes of Snort being unavailable include: policy deployments that restart the Snort process, Snort crashes due to software defects, or Automatic Application Bypass (AAB) events that force Snort restarts when inspection delays exceed thresholds.

Recommendation:

First, determine why Snort is unavailable by checking 'show asp inspect-dp snort' for instance status and reviewing system logs for Snort restart or crash messages (look for syslogs 850001, 850002 for AAB events, or messages about Snort process restarts). If drops occur during policy deployments, this is expected behavior on inline-tap and passive interfaces - consider using prefilter fastpath rules to bypass delay-sensitive traffic that does not require inspection. If Snort is crashing or restarting frequently, collect a troubleshooting bundle and contact Cisco TAC. If you need traffic to continue flowing when Snort is unavailable, reconfigure the interfaces as standard inline interfaces (not inline-tap) and enable the fail-open-down policy; however, this means traffic will bypass inspection during Snort outages. For true monitoring scenarios where drops are unacceptable, consider using SPAN/ERSPAN to a dedicated monitoring interface instead of inline-tap mode.

Syslogs:

850001, 850002

----------------------------------------------------------------

snort-down-no-app-info

Packet dropped because inspection engine is unavailable and flow metadata is missing

This counter increments when the system attempts to send a packet to the inspection engine for deep packet inspection, but the inspection engine is unavailable (down, suspended, or in error state) and the system cannot locate the internal flow metadata required to apply fail-open policies. This is a specific case of inspection engine unavailability where the packet cannot be evaluated for bypass because the necessary flow context structures are missing. The packet is dropped immediately without consulting fail-open configuration. This condition typically occurs during inspection engine restarts, crashes, or internal communication failures between the data plane and the inspection engine, particularly when flows are in transitional states. Note: In some software versions with SSL decryption enabled, this counter may increment spuriously without actual packet loss (cosmetic issue).

Recommendation:

Check the health and status of the inspection engine using 'show snort status' and 'show asp inspect-dp snort'. If the inspection engine is down or restarting, investigate the cause using 'show snort statistics' and system logs for inspection engine crash or restart events (syslog 850002 indicates automatic application bypass due to unresponsive inspection). If the counter increments continuously while the inspection engine shows as healthy and running, and you have SSL decryption policies configured, this may be a known cosmetic counter increment issue that does not indicate actual packet loss—verify traffic is flowing normally. If legitimate drops are occurring, review fail-open configuration ('show running-config snort') to ensure appropriate bypass behavior is configured for your deployment mode. For persistent issues with missing flow metadata during normal operation, collect a troubleshooting bundle and contact Cisco TAC.

Syslogs:

850002 (inspection engine automatic application bypass)

----------------------------------------------------------------

snort-down-not-fp

Packet dropped because Snort inspection engine is unavailable and fail-open is not configured

This counter increments when packets are dropped because the Snort inspection engine is down or unavailable, and the traffic cannot be bypassed. This occurs when:

• The Snort process has stopped, crashed, or is suspended
• The connection requires deep inspection (such as SSL/TLS decryption or application-layer protocol inspection)
• Fail-open mode is not configured on the inline set, OR the connection is in full TCP proxy mode with pending segments that cannot be bypassed
• The packet is not a TCP FIN or RST (connection teardown packets are allowed through even when Snort is down to prevent hung connections)

The behavior depends on interface type and fail-open configuration:

Inline-tap and passive interfaces: Always drop traffic when Snort is down (by design, since these modes require inspection)

Inline interfaces without fail-open: Drop traffic when Snort is unavailable

Inline interfaces with fail-open configured: Bypass inspection and allow traffic to pass, except for connections already in full proxy mode with buffered data awaiting inspection

Once a connection is marked as fail-opened due to Snort being down, it continues to bypass inspection even after Snort recovers.

Recommendation:

1. Check Snort status: Run 'show asp inspect-dp snort' to verify Snort instance health. Look for instances marked as 'Down' or 'Suspended'.

2. Review Snort logs: Check for Snort crashes, memory exhaustion, or configuration errors. Collect 'show tech-support' and review system logs for Snort-related errors or syslog %ASA-3-850002 (Automatic-Application-Bypass events).

3. Consider fail-open configuration: If brief inspection outages are acceptable in your environment, configure fail-open mode on inline sets using 'inline-set <name>' and 'snort fail-open down' to allow traffic to pass when Snort is unavailable. This trades security for availability.

4. Review resource utilization: High CPU or memory usage can cause Snort to become unresponsive. Check 'show cpu', 'show memory', and 'show snort statistics' for resource constraints.

5. For persistent issues: If Snort repeatedly goes down, this may indicate a software defect, resource exhaustion, or configuration problem requiring TAC assistance. Collect a troubleshooting bundle when the issue occurs.

Note: This drop is expected and by-design when Snort is down and fail-open is not configured—it ensures traffic requiring inspection is not passed uninspected. If you see this counter incrementing, Snort availability is the root cause to address.

Syslogs:

850002

----------------------------------------------------------------

snort-drop

Snort inspection engine blocked the packet

This counter increments when the Snort inspection engine determines that a packet should be blocked based on configured security policies. The drop occurs after Snort analyzes the traffic and returns a block verdict to the datapath. Common triggers include intrusion prevention rules configured to drop or block matching traffic, access control policies that deny specific applications or URLs, file policies that block prohibited file types or malware, and security intelligence blocks based on reputation. The counter represents the enforcement point where Snort's inspection decision is applied. On FTD platforms, this is the primary mechanism for policy-based traffic denial after deep packet inspection.

Recommendation:

Review your intrusion policy, access control policy, and file policy configurations to identify which rule or policy is blocking the traffic. Use packet-tracer or packet capture with the connection 5-tuple to see the specific Snort rule ID or policy action that triggered the block. Check the Snort event logs in FMC (Analysis > Intrusion Events or Analysis > Connection Events) for detailed information about why the traffic was blocked, including rule signatures, application identification, or file verdicts. If the block is unintended, adjust the intrusion rule state (disable or change to alert-only), modify access control rule actions, update file policy settings, or create exceptions as appropriate. This counter is expected during normal operation when security policies are actively enforcing traffic restrictions—investigate only if legitimate traffic is being blocked or if the counter is unexpectedly high.

Syslogs:

None directly associated with this counter. Check FMC intrusion events and connection events for details on blocked traffic.

----------------------------------------------------------------

snort-flow-mismatch

Packet returned from inspection with mismatched flow association

This counter increments when the threat defense engine receives a packet back from the Snort inspection process, but the flow association stored in the packet metadata does not match the expected flow context. This validation check protects against memory corruption or stale packet references that could cause system instability. The mismatch typically occurs during deep packet inspection of encrypted traffic (TLS/SSL or QUIC decryption) or Layer 2 packet processing, when packets are sent to Snort for analysis and returned to the datapath for forwarding. When detected, the packet is dropped to prevent potential crashes or incorrect flow processing.

Recommendation:

This counter indicates an internal consistency problem in the packet inspection pipeline. Small, occasional increments may occur during high load or failover events and are typically self-correcting. Sustained or rapidly increasing counts suggest a software defect or resource exhaustion condition. Check for known defects in your software version related to Snort integration, TLS decryption, or QUIC inspection. Review system resource utilization (CPU, memory) and consider reducing inspection load if resources are constrained. If the counter correlates with traffic drops or system instability, collect troubleshooting bundles and contact Cisco TAC, as this may indicate memory corruption requiring a software upgrade.

Syslogs:

None.

----------------------------------------------------------------

snort-inject-data-pkt

Packet dropped after inspection engine injected replacement

This counter increments when the inspection engine injects a new packet into a connection and the original packet is dropped. This is normal behavior for connections using TCP proxy or QUIC proxy features, where the inspection engine may need to inject modified or synthesized packets based on deep inspection results. The original packet that triggered the inspection verdict is silently dropped after the replacement packet is injected into the flow. This commonly occurs with TLS decryption, where the proxy terminates and re-encrypts connections, or during application-layer protocol inspection that requires packet modification. The counter tracks the original packets being replaced, not a failure condition.

Recommendation:

This counter incrementing is expected behavior when TCP proxy or QUIC proxy features are active, particularly with TLS decryption or deep packet inspection policies. No action is required unless you observe connection failures or application issues. If problems occur, verify that the inspection policy is correctly configured and that the injected packets are being transmitted successfully. Check for corresponding increases in packet injection statistics. If injection is failing, review interface configuration and flow state. Enable inspection debug logging only if troubleshooting specific connection issues, as this is normal proxy operation.

Syslogs:

421004

----------------------------------------------------------------

snort-inject-data-pkt-l2-hdr

Original packet dropped during Snort packet injection with L2 header

This counter increments when the threat defense engine (Snort) returns an inject verdict that includes a complete Layer 2 packet header, and the original packet is dropped to make way for the injected replacement packet. This is normal, expected behavior during certain inspection scenarios where Snort needs to modify or replace packet content. The inject verdict is used when Snort determines that a new or modified packet should be sent into the flow instead of the original packet. The original packet is silently dropped (without incrementing error counters) while the new packet from Snort's notification data is extracted and dispatched into the flow. This mechanism supports packet replacement operations and asynchronous communication between the inspection engine and the data plane. The counter specifically tracks L2 header-based injection, as opposed to TCP or QUIC proxy-based injection which uses different drop counters.

Recommendation:

This counter reflects normal operation when Snort-based inspection policies are actively modifying traffic. No action is required. The counter indicates successful packet replacement operations, not errors or dropped connections. If you observe this counter incrementing, it means intrusion prevention or file inspection policies are actively injecting modified packets into flows. This is expected behavior for features like malware blocking with file replacement pages, certain IPS actions that modify packet content, or protocol-specific inspection that requires packet reconstruction. If traffic is not flowing as expected, verify that your intrusion and file policies are configured correctly and that Snort is operating normally using 'show snort status' and 'show asp drop' to check for other error conditions.

Syslogs:

None

----------------------------------------------------------------

snort-invalid-msg

Unrecognized message type returned from Snort inspection

This counter increments when the data path receives a message from a Snort inspection instance with an unrecognized or invalid message type identifier. The data path and Snort communicate via PDTS (Packet Data Transport System) to exchange packets for deep inspection. When Snort returns a packet, the message must contain a valid type identifier indicating what kind of response it is (such as an inspected packet, a decrypted TLS or QUIC packet, a flow verdict, or a debug message). If the message type does not match any expected value, the packet is dropped. This typically indicates a software defect, a version incompatibility between data path and Snort components, or memory corruption affecting the inter-process communication channel. The drop may occur for regular IP traffic, TLS/SSL decrypted traffic, QUIC decrypted traffic, or non-IP Layer 2 frames that were sent to Snort for inspection.

Recommendation:

This counter should normally remain at zero. Any increment indicates an abnormal condition that requires investigation. Check for software version mismatches between FTD components, particularly after an upgrade. Review 'show asp inspect-dp snort counters' for additional PDTS communication errors or queue health issues. Enable debug with 'debug inspect-snort data-plane' and 'debug pdts' to capture detailed message exchange information, including the invalid message type identifier. If the counter increments persistently, collect a troubleshooting bundle and contact Cisco TAC, as this typically indicates a software defect requiring code analysis.

Syslogs:

None.

----------------------------------------------------------------

snort-invalid-verdict

Invalid verdict received from inspection engine

The packet was dropped because the inspection engine returned a verdict that the datapath could not process. This occurs in two situations: (1) the verdict code is out of the valid range of expected values, indicating a communication error between the datapath and inspection engine, or (2) for non-IP packets such as ARP or Layer 2 frames, the inspection engine returned a verdict type other than pass, block, or drop-silent, which are the only verdicts supported for non-IP traffic. This counter typically indicates an internal software issue rather than a configuration problem.

Recommendation:

This drop reason usually points to a software defect in the communication between the datapath and the inspection engine. If you see this counter incrementing, collect a troubleshooting bundle and contact Cisco TAC. Enable inspection debugging to capture detailed information about the invalid verdicts being received. Check for any recent software upgrades or configuration changes that might have triggered the issue. In rare cases, this can occur if the inspection engine sends malformed packet metadata back to the datapath after processing, which has been addressed in various software releases.

Syslogs:

None

----------------------------------------------------------------

snort-module

Packet blocked by intrusion prevention inspection

The intrusion prevention system inspection engine determined that this packet or flow should be blocked. This occurs when traffic matches an intrusion prevention rule configured with a Drop or Block action, or when a source or destination IP address is on a security intelligence blacklist. The inspection engine sends a block verdict back to the datapath, which increments this counter and drops the packet. This is normal operation when intrusion prevention policies are actively enforcing security rules. The counter applies to both individual packet blocks (when a single packet triggers a signature) and flow-level blacklist verdicts (when an entire connection is blocked based on reputation).

Recommendation:

This counter indicates that intrusion prevention is working as designed. To understand which rule or policy caused the block, use packet tracer to simulate the traffic and view the intrusion prevention verdict details, or enable packet capture with trace to see the inspection decision for live traffic. Check the intrusion events in the management center to identify the specific signature or security intelligence category that triggered the block. If legitimate traffic is being blocked, review the intrusion policy rule actions and security intelligence blacklist configuration. For troubleshooting, examine the output of 'show service-policy' to see per-policy intrusion prevention statistics including packets inspected and dropped. If blocks occur during large file transfers, verify that network analysis policy stream reassembly limits are appropriate for your traffic patterns.

Syslogs:

420002

----------------------------------------------------------------

snort-react

Packet dropped by intrusion rule with react action

This counter increments when the intrusion prevention system (Snort) drops a packet due to a triggered intrusion rule configured with the 'react' action. The react action is a special rule action that not only blocks the offending traffic but also sends a custom HTML response page back to the client before terminating the connection. This is typically used to notify users that their request was blocked by security policy. The counter tracks packets dropped after Snort issues the react verdict, which occurs when traffic matches an intrusion rule signature configured with this action type in your intrusion policy.

Recommendation:

This drop is expected behavior when intrusion rules with the react action are triggered. To investigate: (1) Use packet-tracer to identify which intrusion rule fired and caused the react verdict. (2) Review your intrusion policy on FMC to see which rules are configured with the react action - these are typically custom rules rather than Cisco-provided signatures. (3) Check the Snort event logs in FMC to see the specific signature ID and rule details. (4) If the drops are unintended, either modify the rule action from 'react' to 'alert' (to log without blocking), adjust the rule signature to reduce false positives, or disable the rule entirely. (5) Note that the react action is a legacy feature from Snort 2; in modern deployments, consider using standard 'block' or 'drop' actions instead, as react adds overhead by generating and injecting HTML responses. If you see this counter incrementing but did not intentionally configure react rules, review your custom intrusion rules for unintended action settings.

Syslogs:

420002

----------------------------------------------------------------

snort-replace-data-pkt

Packet replaced by intrusion prevention system

This counter increments when the intrusion prevention system modifies packet content in response to an IPS rule with a replace action. On Firepower 2100 series platforms, packet content cannot be modified in place, so the original packet is dropped and a new packet containing the modified content is forwarded. This is normal operation when IPS rules are configured to replace specific byte patterns in traffic (for example, replacing malicious content or sanitizing protocol fields). The counter tracks the original packets that are dropped as part of the replacement process; the modified packets are forwarded normally and do not appear in drop statistics.

Recommendation:

This counter incrementing is expected behavior when IPS policies include rules with replace actions and those rules match traffic. Review your intrusion policy to identify which rules use replace actions. If the counter increments unexpectedly, verify that the IPS rules are matching the intended traffic patterns. If you are not using any IPS rules with replace actions but this counter is incrementing, contact Cisco TAC for further investigation. Note that this behavior is specific to Firepower 2100 series platforms; other platforms may handle packet replacement differently.

Syslogs:

None.

----------------------------------------------------------------

snort-response

Blocked by intrusion rule active response action

This counter increments when traffic is blocked by an active response action configured in an intrusion rule. Active responses are automated defensive actions that the intrusion detection system can take when it detects malicious or policy-violating traffic, such as sending TCP resets to terminate connections or ICMP unreachable messages to block hosts. The counter fires when the intrusion engine determines that a packet should be dropped as part of executing one of these active response actions. This is distinct from normal intrusion rule blocks—it specifically tracks drops resulting from the active response mechanism rather than the intrusion rule match itself.

Recommendation:

Review the intrusion policy configuration to identify which rules have active responses enabled. Use packet tracer with intrusion event logging to see which specific rule triggered the active response and what type of response action was taken (TCP reset, ICMP unreachable, etc.). If the counter is incrementing unexpectedly, verify that active responses are configured only for rules where automated blocking is appropriate—some environments may prefer alert-only mode for certain rule categories. Check the 'show snort' output and intrusion event logs to correlate the drops with specific threat detections. This counter incrementing is expected behavior when active responses are configured and threats are detected; it becomes a concern only if legitimate traffic is being blocked due to false positives or overly aggressive active response settings.

Syslogs:

None directly associated with this counter. Intrusion events that trigger active responses will generate standard intrusion event logs visible in the intrusion event viewer or syslog stream if intrusion logging is enabled.

----------------------------------------------------------------

snort-silent-drop

Original packet dropped during inspection engine packet injection or replacement

This counter increments when the inspection engine performs a packet injection or replacement operation and the original packet is dropped as part of normal processing. This occurs in three main scenarios: (1) When deep packet inspection features inject modified or replacement packets into a flow (such as content filtering or data masking operations), (2) When TLS Server Identity Discovery or other TLS decryption features use TCP proxy to inject certificate probe packets or responses, and (3) When the inspection engine replaces packet content in-place on certain platforms. The original packet is dropped 'silently' because it is being superseded by the injected or modified packet—this is expected behavior, not an error. The replacement packet continues through the firewall normally. This counter is most commonly seen on FTD devices running in inline or IPS mode with intrusion prevention policies, TLS decryption, or advanced inspection features enabled.

Recommendation:

This counter incrementing is normal and expected when using deep packet inspection, intrusion prevention, or TLS decryption features. No action is required unless the counter is increasing without any of these features configured, or if you observe actual traffic disruption. If troubleshooting related flow issues, enable 'debug snort' or 'debug pdts' to see detailed verdict processing and understand which inspection feature is performing the injection or replacement. Review the inspection policy configuration if unexpected packet modifications are occurring. Note that this counter does not indicate dropped user traffic—the injected or replaced packets are forwarded normally.

Syslogs:

None. Related syslog 421004 may appear if packet injection fails.

----------------------------------------------------------------

snp-ha-udp-lu-link-resource-alloc-failure

Failover dropped packet on LU channel due to memory allocation failure

This counter increments when the standby unit drops a packet received on the failover Logical Update (LU) channel because the system cannot allocate the internal metadata structure needed to process the packet. The LU channel carries state synchronization updates from the active unit to the standby unit in high-availability configurations that use UDP-based transport. The allocation failure occurs when either system memory or packet buffer extension memory is exhausted. This typically happens during periods of high connection scale (millions of concurrent connections) or sustained memory pressure, and results in the standby unit missing state updates for some connections.

Recommendation:

Check memory utilization on the standby unit using 'show memory' and 'show blocks'. If system memory is consistently above 80%, investigate memory consumers with 'show memory detail'. If specific block sizes show low free counts in 'show blocks', this indicates packet buffer exhaustion—common during high throughput or connection scale. At very high connection counts (5 million or more), consider upgrading to a release with improved LU channel handling (fixed in 7.4.1+, 9.20.2+). If drops persist and memory appears adequate, contact Cisco TAC with output from 'show failover', 'show memory', 'show blocks', and 'show asp drop' to investigate potential resource leaks or scaling limits.

Syslogs:

None

----------------------------------------------------------------

snp-ha-udp-lu-link-unexpected-packet

Failover UDP transport received packet for wrong destination entity

This counter increments when a packet arrives on the failover stateful link using UDP transport, but the packet's internal routing header indicates it is destined for a control-plane entity rather than the network processor. UDP transport for failover is used on high-throughput platforms to distribute state replication traffic across multiple CPU cores by varying the UDP source port. Only network processor entities should use UDP transport; control-plane entities use a different transport mechanism. This drop is a defensive check that prevents misrouted packets from being processed incorrectly.

Recommendation:

This counter should remain at zero during normal operation. If it increments, verify that both failover peers are running compatible software versions and that the failover link is not receiving unexpected traffic from other sources. Check for any failover configuration mismatches between the peers. If the counter increments persistently and both units are running the same software version with matching configurations, capture traffic on the failover link and contact Cisco TAC, as this may indicate a software defect in the failover state replication logic.

Syslogs:

None

----------------------------------------------------------------

sp-security-failed

Slowpath security checks failed

The firewall dropped a packet that failed basic IP address security validation. This counter increments for several types of invalid addressing:

In routed mode, the firewall blocks Layer 2 broadcast frames from traversing the device (broadcasts should not cross routing boundaries).

For IPv4 packets in both routed and transparent modes, the firewall enforces RFC compliance by rejecting packets with:

• Source or destination addresses of 0.0.0.0 (except DHCP discovery packets, which use 0.0.0.0 as source and are permitted in transparent mode and on bridge virtual interfaces)
• Source addresses in the loopback range (127.0.0.0/8) or with a first octet of zero
• Source addresses where the network portion is all zeros or all ones
• Source addresses where the host portion is all zeros or all ones (network or broadcast addresses used as host addresses)
• Destination addresses using obsolete broadcast formats (all-zeros network addresses)
• Identical source and destination IP addresses (Land Attack pattern)

These checks protect against address spoofing, malformed packets, and known attack patterns. The firewall exempts certain legitimate traffic: loopback interfaces, traffic to or from the device itself, inline IPS interfaces, and DHCP client discovery packets are not subject to all validation rules.

Recommendation:

First, determine whether the drops represent a security threat or legitimate traffic being blocked:

Check the associated syslogs (106016 for IP spoofing, 106017 for Land Attacks) to identify the source and destination addresses. Use packet capture to examine the actual traffic: 'capture <name> type asp-drop sp-security-failed' (note: matching on specific addresses may not work in older releases; capture all drops and filter the output).

Common benign causes:

• High-availability failover hello packets during interface failures or failover events may briefly trigger Land Attack detection (source and destination are the same standby IP). This is cosmetic and stops when connectivity is restored.
• BFD echo packets may trigger false positives in releases prior to 9.6(2) and 9.7(1). Upgrade if BFD is in use.
• DHCP relay or client traffic should not trigger drops in transparent mode, but may in routed mode if misconfigured.

If the source MAC address or IP indicates an external host, investigate:

• Misconfigured clients sending packets with invalid source addresses (0.0.0.0, loopback, or broadcast addresses)
• Malicious traffic attempting address spoofing or Land Attack exploits
• Routing or NAT misconfigurations causing packets to arrive with unexpected addresses

If drops are rapid and continuous from external sources, this may indicate an active attack. Identify the source interface and upstream device, and consider applying access control lists to block the offending traffic at the network edge.

Syslogs:

106016, 106017

----------------------------------------------------------------

ssl-alert-length-invalid

SSL/TLS Alert Record Length Invalid

The device received an SSL or TLS alert record with an invalid payload length. According to the TLS specification, alert messages must contain exactly 2 bytes: one byte for the alert level (warning or fatal) and one byte for the alert description. This counter increments when the device is performing SSL decryption and encounters an alert record with a payload shorter than 2 bytes. This typically indicates malformed SSL/TLS traffic from a misconfigured client or server, a protocol implementation error, or potentially malicious traffic attempting to exploit SSL/TLS parsing vulnerabilities. The connection is terminated when this condition is detected.

Recommendation:

This drop is a security measure that protects against malformed SSL/TLS traffic. Investigate the source of the invalid alert messages:

1. Check whether the traffic originates from a legitimate application with a known SSL/TLS implementation bug 2. Verify that SSL decryption policies are correctly configured and applied to the appropriate traffic 3. Use packet captures to examine the malformed alert record and identify the sending endpoint 4. If the drops are frequent and affecting legitimate traffic, check for SSL/TLS library version mismatches or outdated client/server implementations 5. Review the SSL decryption logs to identify which connections are being dropped

This counter should remain at zero or very low in normal operations. Sustained increases may indicate an attack attempt or a systematic protocol implementation problem on one of your endpoints. Contact Cisco TAC if legitimate traffic is being dropped.

Syslogs:

None

----------------------------------------------------------------

ssl-first-record-invalid

SSL/DTLS First Record Invalid

The device received an SSL or DTLS packet that failed initial protocol validation. For DTLS connections (commonly used by AnyConnect VPN for UDP transport), this counter increments when the very first packet of a new session either has an incorrect protocol version number or is not a handshake message. DTLS sessions must begin with a proper handshake packet; receiving application data, alerts, or other message types as the first packet violates the protocol and indicates either a malformed client, an attack attempt, or packets arriving out of order. For legacy SSL version 2 client hello messages (rarely seen in modern deployments), the minimum record length is 11 bytes; shorter records are rejected. The connection is terminated when this validation fails.

Recommendation:

This drop is a security enforcement and is typically correct behavior when rejecting malformed or out-of-sequence traffic. Investigate the source of the dropped packets. For AnyConnect DTLS VPN connections, verify that clients are using supported DTLS versions and that UDP packets are not being reordered or corrupted in transit. If the counter increments during normal VPN operations, check for network devices (firewalls, NAT gateways, or load balancers) that may be fragmenting, reordering, or inspecting UDP traffic in ways that corrupt DTLS packets. Packet captures showing the rejected traffic can help identify whether the issue is a misconfigured client, a protocol downgrade attack, or network path problems. If the drops occur only for specific clients or network paths, focus troubleshooting on those segments. This counter should remain at zero or very low in healthy deployments.

Syslogs:

None

----------------------------------------------------------------

ssl-preproc

Blocked by SSL decryption policy

Traffic was dropped because it matched an SSL decryption policy rule with a Block or Block with Reset action. This counter increments when the SSL/TLS inspection engine evaluates encrypted connections against the configured decryption policy and determines the traffic should be blocked based on certificate validation failures, URL category restrictions, application filtering, or explicit block rules. This is a policy enforcement action, not an error condition. The drop occurs during the SSL handshake inspection phase before the connection is fully established.

Recommendation:

Review the SSL decryption policy configuration to identify which rule triggered the block action. Use 'packet-tracer' to simulate the connection and view the SSL policy verdict, or examine connection events in the Firewall Management Center to see the specific SSL rule and block reason. If legitimate traffic is being blocked, adjust the SSL policy by adding a 'Do Not Decrypt' rule for the affected traffic, modifying certificate trust settings, or changing the rule action. Verify that certificate validation settings and URL category filtering are configured as intended. If the block is intentional, no action is required.

Syslogs:

None

----------------------------------------------------------------

ssl-record-length-invalid

SSL handshake record too short

The device received an SSL or TLS handshake record that is shorter than the minimum required length. During SSL/TLS decryption operations, the device validates that handshake records contain at least 4 bytes (the minimum handshake message header). This counter increments when a handshake record arrives with fewer than 4 bytes, which violates the TLS specification and prevents proper handshake processing. The connection is terminated because the malformed record cannot be safely processed. This typically occurs when SSL/TLS decryption policies (decrypt-resign, decrypt-known-key, or do-not-decrypt with inspection) are active and the device is acting as a TLS proxy or inspector.

Recommendation:

This drop indicates malformed or corrupted SSL/TLS traffic reaching the device. Common causes include: (1) A client or server with a buggy TLS implementation sending truncated handshake messages, (2) Network corruption or fragmentation issues causing handshake records to arrive incomplete, (3) An attacker attempting to exploit TLS parsing vulnerabilities with malformed packets. If this counter increments regularly: verify that clients and servers use standards-compliant TLS implementations; check for network issues (MTU problems, packet corruption) between endpoints and the device; review packet captures to identify which endpoint is sending malformed handshakes; consider whether the traffic is legitimate or represents a security probe. Occasional increments from untrusted sources (Internet-facing interfaces) are normal and indicate the device is correctly rejecting invalid traffic. Frequent increments from trusted internal clients or servers warrant investigation of the endpoint TLS stack.

Syslogs:

None

----------------------------------------------------------------

ssm-app-fail

Service module unavailable

Packets requiring inspection by a Security Services Module (SSM) were dropped because the module or its application is not operational. This counter applies to ASA 5500 series platforms with SSM hardware modules such as IPS/AIP-SSM, CSC (Content Security and Control), CX, or SFR. The drop occurs when traffic is diverted to the module for inspection but the module application is not running, or when the module returns traffic with an invalid protocol header. Common causes include: the module is in an unresponsive or initializing state, undergoing software or signature updates, administratively shut down, experiencing hardware or software failure, or physically removed while inspection policy remains configured.

Recommendation:

Check the module status with 'show module' and 'show module <slot> details'. If the module shows as 'Down', 'Unresponsive', or 'Recover', investigate module health using 'show service-module' commands and review system messages for module failure alerts. If the module was intentionally shut down or removed, either remove the inspection policy configuration (e.g., 'ips', 'csc', 'cxsc' commands in the service policy) or configure fail-open mode to allow traffic to pass uninspected during module unavailability. If the module is undergoing an upgrade, the counter is expected and will clear once the module returns to service. For persistent unresponsive states or hardware failures, consult the module-specific troubleshooting documentation or contact Cisco TAC.

Syslogs:

420001 (IPS card not up with fail-close mode)

----------------------------------------------------------------

ssm-app-request

Service module requested drop

This counter increments when a Security Services Module (SSM) — such as the AIP-SSM (IPS), CSC-SSM (Content Security and Control), or other application modules on ASA 5500 series platforms — instructs the ASA to drop a packet or tear down a connection. The SSM examines diverted traffic inline and can request three actions: allow the packet to continue (inject), drop the packet (tear down), or drop the packet and reset the connection. This counter tracks the tear-down and reset actions. The drop occurs after the SSM has inspected the traffic and determined it violates a security policy (such as an IPS signature match, malware detection, or content filtering rule). This is normal operation when the SSM is actively blocking threats. The counter applies only to legacy ASA 5500 series hardware with physical SSM modules; it does not apply to modern FTD platforms or ASA 5500-X series with FirePOWER services.

Recommendation:

Review the SSM's own logs and incident reports to identify why traffic was blocked. For AIP-SSM (IPS), check 'show ips' on the ASA and review IPS event logs on the module itself to see which signatures or policies triggered the drop. For CSC-SSM, consult the Trend Micro management interface for anti-virus or content filtering verdicts. If legitimate traffic is being dropped, adjust the SSM's security policies (signature tuning, whitelist exceptions, or policy modifications). Verify the service policy is correctly applied using 'show service-policy' and confirm traffic classification matches your intent. If the SSM is offline or in a failed state, check 'show module' — traffic may be dropped due to fail-close behavior (see syslog %ASA-3-420001). If the SSM should not be inspecting certain traffic (such as VPN tunnels experiencing fragmentation issues), exclude that traffic from the service policy using class-map match criteria. This counter is expected during normal threat-blocking operations; investigate only if legitimate traffic is affected or the rate is unexpectedly high.

Syslogs:

420002

----------------------------------------------------------------

ssm-asdp-invalid

Invalid packet received from service module

The security appliance received a packet from an installed service module (such as CSC-SSM or AIP-SSM) over the internal backplane, but could not process it due to a protocol error. This counter applies only to ASA 5500 series platforms with service modules installed. The appliance and service module communicate using a proprietary protocol for traffic inspection and injection. Packets are dropped when the protocol header is malformed, the protocol version is incompatible between the appliance and module software, the connection referenced by the packet no longer exists in the appliance connection table, or the appliance has transitioned to standby state in a failover pair. Small increments are expected during normal operation when connections are cleared via the command-line interface or during failover events, because the appliance and service module maintain independent connection state and brief timing differences can cause the module to reference already-closed connections.

Recommendation:

A counter value of zero or small increments over time is normal. If the counter increases rapidly during steady-state operation, verify that the appliance and service module are running compatible software versions by checking the output of 'show module' for version compatibility warnings. If version mismatch messages appear in the system log, upgrade either the appliance or the service module software to compatible versions as indicated in the compatibility matrix. If versions are compatible but the counter continues to increase, the service module may be experiencing internal software issues; attempt to recover the module using 'hw-module module <slot> recover' or reload it using 'hw-module module <slot> reload'. If the problem persists after module recovery, contact Cisco Technical Assistance Center with the output of 'show tech-support' and 'show module' from both the appliance and service module.

Syslogs:

421003 421004

----------------------------------------------------------------

ssm-dpp-invalid

Packet received from SSM module before driver initialization

This counter applies only to ASA 5500 and 5500-X series platforms with Security Services Modules (SSM) installed, including IPS, CX (Context-Aware Security), or SFR (Sourcefire) modules. The counter increments when the ASA receives a packet from the SSM module over the internal backplane interface, but the module-specific packet handler has not yet been registered. This typically occurs during system startup when the backplane communication channel becomes active before the SSM driver completes its initialization sequence. Each SSM type (IPS, CX, SFR) must register a receive callback handler to process packets returning from the module; packets arriving before this registration completes are dropped and counted here.

Recommendation:

A small number of drops (typically fewer than 10) during system boot or SSM module initialization is normal and expected behavior due to the initialization timing. The counter should remain at zero or a low static value once the system is fully operational. If this counter continues to increment steadily after the ASA and SSM module have completed startup, it indicates a problem with the SSM driver initialization or backplane communication. Verify the SSM module status with 'show module' and check for module errors or repeated reloads. If the counter rises continuously during normal operation, contact Cisco TAC for assistance, as this may indicate a driver or hardware issue requiring further diagnosis.

Syslogs:

None.

----------------------------------------------------------------

stream

Blocked by Snort stream preprocessor

This counter increments when the Snort stream preprocessor blocks a packet. The stream preprocessor is responsible for TCP connection tracking, stream reassembly, and TCP normalization. It can block packets for various reasons including TCP state violations, reassembly anomalies, stream policy violations, or when TCP traffic does not conform to the configured stream policy settings. This drop occurs on FTD platforms where traffic is inspected by Snort. The specific reason for the block is determined by Snort's stream inspection engine based on the active intrusion policy and stream preprocessor configuration.

Recommendation:

Use packet tracer or enable capture with trace to see the detailed Snort verdict information, which will show the specific stream preprocessor rule or condition that triggered the block. Review the intrusion policy settings related to stream preprocessor configuration, including TCP stream reassembly settings, stream policy mode (inline vs. inline-tap), and any custom stream preprocessor rules. Check for TCP anomalies in the traffic such as out-of-order segments, retransmissions, or state violations. If the drops are unexpected, verify that the stream preprocessor settings match your network's TCP behavior requirements. For asymmetric routing scenarios where only one side of the TCP conversation is visible, consider adjusting the stream preprocessor configuration or using prefilter rules to bypass inspection for affected flows.

Syslogs:

None.

----------------------------------------------------------------

sts-lookup-failure

Tag-switching table lookup failure

The device dropped a packet because it could not find a matching entry in the tag-switching table to translate the ingress VXLAN segment identifier to an egress segment identifier. This occurs when VXLAN overlay networks use segment-to-segment translation (tag-switching) on VNI interfaces, and the device receives a packet with an ingress segment identifier that has no corresponding egress mapping in the locally cached translation table. The tag-switching table is populated by an external fabric controller via HTTPS and must contain mappings for all segment identifiers that will traverse the device. Common causes include: the fabric controller has not yet pushed the complete table to the device, the table is out of sync with the current network topology, a new segment has been added to the fabric but the mapping has not been distributed, or the device is operating in fabric-controller management mode but has lost connectivity to the controller.

Recommendation:

Check syslog message 779001 to identify the specific ingress segment identifier that failed lookup. Verify that the device is configured for fabric-controller management mode if tag-switching is intended. Confirm connectivity between the device and the fabric controller. Use show commands to inspect the current tag-switching table contents and verify that mappings exist for all segment identifiers in use on ingress VNI interfaces. If the table is empty or incomplete, investigate whether the fabric controller is operational and able to push updates. If drops persist after the table is populated, verify that the network topology matches the controller's view and that all required segment-to-segment mappings have been defined in the fabric controller configuration. Contact Cisco TAC if the fabric controller is operational but the device is not receiving table updates.

Syslogs:

779001

----------------------------------------------------------------

sts-nat-diff-egress

VXLAN Service Tag Switching and NAT select different egress interfaces

This counter increments when VXLAN traffic with Service Tag Switching (STS) enabled encounters a configuration conflict between the STS segment-id translation table and NAT policy. During packet processing, STS performs a segment-id lookup to determine which VXLAN VNI interface should be used for egress, while NAT policy independently determines an egress interface based on the translated addresses. When these two mechanisms select different interfaces, the packet is dropped and this counter increments. This scenario occurs only in VXLAN overlay deployments where both STS (for fabric integration and segment-to-segment forwarding) and NAT are configured on the same traffic flows. The accompanying syslog 779002 identifies the segment-id and flow 5-tuple involved in the conflict.

Recommendation:

Review the NAT policy configuration to ensure it aligns with the VXLAN STS segment-id translation mappings. Verify that NAT rules applied to VXLAN inner traffic specify egress interfaces that match the VNI interfaces selected by the STS table for the corresponding segment-ids. Check the STS table mappings using VXLAN show commands to confirm which VNI interface is associated with each segment-id, then adjust NAT policy interface specifications accordingly. If NAT is not required for the VXLAN overlay traffic, consider exempting these flows from NAT. This drop is informational and indicates a configuration mismatch rather than a platform or software defect.

Syslogs:

779002

----------------------------------------------------------------

suppress-icmpv6-loopback

ICMPv6 Packet Too Big suppressed for encrypted VTI traffic on loopback

This counter increments when the appliance suppresses generation of an ICMPv6 'Packet Too Big' error message for encrypted VPN traffic where the source and destination IPv6 addresses are identical and the interface is a loopback interface. This scenario occurs with Virtual Tunnel Interface (VTI) configurations that use a loopback interface as the tunnel source, particularly during IPsec rekey operations when through-the-box traffic exceeds the configured MTU. The appliance suppresses the error message because it would be sent to the loopback interface itself (making it useless for path MTU discovery) and would trigger false LAND attack alarms. The counter indicates that oversized packets are being sent from the LAN side through the VPN tunnel.

Recommendation:

This is expected behavior for VTI configurations using loopback tunnel sources. If this counter increments frequently, verify that the MTU configuration on the LAN-side interfaces and hosts is appropriate for the VPN tunnel overhead (typically 1400-1440 bytes for IPv6 IPsec). Consider enabling 'crypto ipsec fragmentation before-encryption' on the tunnel interface to fragment packets before encryption, or adjust the MTU on LAN-side hosts to prevent oversized packets from reaching the tunnel. No action is required if traffic is flowing normally; the counter simply indicates that unnecessary ICMPv6 errors are being suppressed.

Syslogs:

None. This counter prevents syslog %ASA-2-106017 (LAND attack) from being incorrectly triggered.

----------------------------------------------------------------

tcp-3whs-failed

TCP Three-Way Handshake Validation Failure

The device dropped a TCP packet because it violated the expected three-way handshake sequence. This occurs when TCP normalization detects packets arriving in the wrong direction or with invalid parameters during connection establishment. Common examples include: a SYN-ACK packet arriving from the client instead of the server, an ACK packet arriving from the server when it should come from the client, duplicate SYN or SYN-ACK packets with mismatched sequence or acknowledgment numbers, or unexpected packet types (such as pure ACK packets) arriving before the handshake completes. The device tracks TCP state for each connection and enforces strict handshake ordering to prevent spoofing and ensure connection integrity. This counter may increment during network scanning activity, asymmetric routing where the device sees only one direction of traffic, packet replay attacks, or when endpoints have inconsistent views of connection state. In clustering deployments, this can occur when handshake packets are processed by different cluster members without proper state synchronization.

Recommendation:

Low rates are normal and typically indicate scanning activity or occasional misrouted packets. Investigate if the counter increments rapidly or affects legitimate traffic. Use packet captures to identify the specific handshake violation—look for packets with unexpected TCP flags, wrong direction flows, or sequence number mismatches. Check for asymmetric routing where the device may not see the complete handshake in both directions; if present, adjust routing or use connection state bypass for affected flows. In cluster deployments, verify that director assignment is stable and that cluster members are properly synchronizing connection state during handshake establishment. If the drops affect specific applications, consider using TCP state bypass or prefilter rules to exclude that traffic from stateful inspection. Review any recent changes to NAT configuration, load balancers, or network topology that might cause the device to see handshake packets out of sequence or from unexpected directions.

Syslogs:

None

----------------------------------------------------------------

tcp-ack-syn-diff

Duplicate SYN-ACK with mismatched acknowledgement number

The device drops a duplicate SYN-ACK packet during the three-way handshake because its acknowledgement number does not match the expected client sequence number. This occurs when the device has already received a valid SYN-ACK from the server and is waiting for the final ACK from the client to complete the handshake. If a second SYN-ACK arrives with a different acknowledgement number than the first, it indicates an inconsistency that could result from network issues, retransmissions with modified parameters, asymmetric routing, or potential connection hijacking attempts. The TCP normalizer drops the inconsistent packet to maintain connection state integrity.

Recommendation:

This counter typically indicates network instability, retransmission issues, or middlebox interference during connection establishment. Investigate whether retransmitted SYN-ACK packets are being modified in transit by load balancers, proxies, or other network devices. Check for asymmetric routing that might cause the device to see SYN packets from different paths with varying sequence numbers. If the counter increments frequently for legitimate traffic, verify that network devices between the client and server are not altering TCP sequence or acknowledgement numbers. In most cases, the drop is protective and prevents connection state corruption; the client will typically retry and establish the connection successfully. Contact Cisco TAC if legitimate connections consistently fail to establish.

Syslogs:

None

----------------------------------------------------------------

tcp-acked

Duplicate TCP Retransmission Already Acknowledged

The firewall received a retransmitted TCP data packet whose sequence range has already been acknowledged by the peer endpoint. This occurs when TCP normalizer's retransmit checking feature is enabled and detects that the sender is retransmitting data that the receiver has already confirmed receipt of. This is normal TCP behavior in networks experiencing packet loss or delay—the sender's retransmission timer may expire before it receives the acknowledgment, causing it to retransmit data that has actually been delivered. The firewall drops these redundant packets to prevent duplicate data delivery and optimize throughput.

Recommendation:

This counter incrementing is expected and benign in most environments. It indicates normal TCP retransmission behavior and does not represent a problem with the firewall or the connection. High values may indicate network conditions such as packet loss, high latency, or asymmetric routing causing delayed acknowledgments. If this counter is incrementing excessively on specific connections, investigate the network path for packet loss or latency issues. No firewall configuration changes are typically needed. This drop only occurs when TCP normalizer retransmit checking is enabled (the default behavior for stateful TCP inspection).

Syslogs:

None

----------------------------------------------------------------

tcp-bad-option-length

TCP option has invalid length field

The appliance received a TCP packet with a malformed options field. Specifically, a TCP option (other than NOP or End-of-Options) has a length field of zero or a length that extends beyond the TCP header boundary. According to RFC 793, all TCP options except NOP (option 1) and End-of-Options (option 0) must include a length field of at least 2 bytes (1 byte for type, 1 byte for length). A zero-length option would cause the parser to loop indefinitely without advancing to the next option. This drop protects against malformed packets that could cause processing delays or denial of service. This counter typically increments when the appliance is configured with dual TCP normalization (normalization occurs at both ingress and egress), and a packet's TCP options become corrupted between the first and second normalization pass—for example, when a packet is redirected to an inspection engine like Snort or undergoes content modification that inadvertently corrupts the options field.

Recommendation:

This drop indicates receipt of a malformed TCP packet that violates the TCP specification. In most cases, this is benign protection against malformed traffic from the internet or from misbehaving endpoints. If this counter increments frequently for legitimate traffic: (1) Capture the dropped packets using 'capture asp-drop tcp-bad-option-length' to identify the source and examine the malformed options field. (2) Check whether the traffic is being modified by an intermediate device (load balancer, WAN optimizer, or security appliance) that may be corrupting TCP options. (3) If the drops occur only with specific applications or endpoints, investigate whether those systems have TCP stack bugs or non-standard TCP option implementations. (4) Review your TCP normalization policy ('tcp-map' configuration) to ensure it is appropriate for your environment. If drops correlate with traffic redirected to Snort or other inspection engines, contact Cisco TAC as this may indicate an issue with packet handling during inspection redirection.

Syslogs:

None

----------------------------------------------------------------

tcp-bad-option-list

TCP option not recognized by normalizer

The appliance dropped a TCP packet because it contained a TCP option that is not explicitly recognized by the TCP normalizer, and the policy for handling such options is configured to drop. The TCP normalizer explicitly handles standard options including MSS (option 2), window scale (option 3), SACK-permitted (option 4), SACK (option 5), timestamp (option 8), and MD5 signature (option 19). Any other option type encountered in the TCP header is subject to the configured action for unrecognized options. By default, the normalizer allows unrecognized options to pass through, but if a TCP map is configured with a drop action for specific option ranges or for all other options, packets containing those options will be dropped and this counter incremented. This can occur with experimental TCP options, vendor-specific extensions, or obsolete option types that some operating systems or applications still use.

Recommendation:

Review your TCP map configuration to determine which TCP options are configured to be dropped. Use 'show run tcp-map' to view the current policy. If legitimate traffic is being dropped, you have three options: (1) Configure the tcp-options command in the TCP map to 'allow' the specific option range that is being dropped, (2) Configure the tcp-options command to 'clear' instead of 'drop' to strip the unrecognized options while allowing the packet to pass, or (3) Remove the restrictive tcp-options configuration to use the default behavior of allowing all options. Common scenarios include: TCP Fast Open (option 34), Multipath TCP options (option 30), or other experimental options defined in RFCs. If you are unsure which specific option is triggering the drop, enable packet capture on the interface with 'capture' command and filter for TCP traffic to identify the option type in dropped packets. Contact Cisco TAC if drops persist after adjusting the TCP map policy and you need assistance identifying the problematic option.

Syslogs:

None

----------------------------------------------------------------

tcp-buffer-full

TCP Out-of-Order Packet Buffer Full

The device received an out-of-order TCP packet on a connection that requires packet reordering, but the per-connection reorder queue for that direction has reached its maximum capacity. The device drops the packet and sends a duplicate acknowledgment to the sender to trigger fast retransmit. TCP packet reordering is enabled automatically when traffic requires deep inspection (such as application inspection, intrusion prevention, or URL filtering) or when explicitly configured via a tcp-map with a queue-limit. Each connection maintains separate reorder queues for each direction (client-to-server and server-to-client). When out-of-order packets arrive faster than they can be processed and delivered in sequence, the queue fills. Once full, additional out-of-order packets are dropped until queue space becomes available. This typically occurs during periods of network congestion, packet loss, or route asymmetry combined with inspection that requires in-order delivery.

Recommendation:

Occasional drops are normal during transient network issues and TCP will recover through retransmission. If drops are frequent or sustained: (1) Verify network path quality—check for congestion, packet loss, or asymmetric routing that causes excessive out-of-order delivery. (2) On ASA platforms, increase the per-connection queue depth using the 'queue-limit' command under a tcp-map (default is typically 0, which enables minimal buffering only when inspection requires it; values up to 250 packets per direction are supported). (3) Review which traffic classes require deep inspection—consider using prefilter rules to bypass inspection for bulk data transfers that do not require security inspection. (4) For FTD with TLS Server Identity Discovery enabled, verify you are running a version with fixes for known out-of-order handling issues (see CSCwr85470). (5) Monitor the related 'tcp-buffer-timeout' counter—if both counters increment together, packets are being queued but timing out before the missing in-sequence packets arrive, indicating more severe reordering or loss. Contact Cisco TAC if drops persist after tuning, especially if accompanied by application failures.

Syslogs:

None

----------------------------------------------------------------

tcp-buffer-timeout

TCP Out-of-Order Packet Buffer Timeout

This counter increments when out-of-order TCP packets have been queued for reordering but the expected in-sequence packet does not arrive within the configured timeout period, causing the queued packets to be dropped. The device queues out-of-order packets when TCP normalization is active on inspected connections, attempting to deliver packets to application inspections or security modules in the correct sequence. If network conditions prevent the missing packet from arriving before the timeout expires (default varies by platform), all queued packets for that direction are dropped and the counter increments. This typically occurs during periods of packet loss, significant network delay, or asymmetric routing where packets take different paths with varying latency. The behavior is controlled by the 'queue-limit' command in TCP maps, which sets both the maximum number of packets to queue and the timeout duration.

Recommendation:

Small numbers of these drops are normal in networks with occasional packet loss or reordering, as TCP's retransmission mechanism will recover the connection. Investigate if the counter is incrementing rapidly or if users report connection slowness or failures. Check for network congestion, packet loss, or asymmetric routing between the client and server. Use packet captures on both interfaces to confirm whether packets are arriving out of order and whether the missing in-sequence packets eventually arrive. If drops correlate with specific traffic types (such as large file transfers over VPN tunnels), consider increasing the timeout value using 'tcp-map' configuration with 'queue-limit <count> timeout <seconds>'. For traffic that does not require strict ordering or deep inspection, consider bypassing TCP normalization using class-maps and 'set connection advanced-options tcp-state-bypass'. Contact Cisco TAC if drops persist after tuning or if they correlate with application failures.

Syslogs:

None

----------------------------------------------------------------

tcp-conn-limit

TCP connection limit reached

This counter increments when a TCP connection completes its three-way handshake but cannot transition to the established state because the configured maximum connection limit has been reached. The limit is enforced by Modular Policy Framework service policies using the 'set connection conn-max' command applied to specific traffic classes. This is distinct from embryonic connection limits, which apply during the handshake phase. The packet that would complete the connection is dropped, and the connection is torn down. This typically occurs when legitimate traffic exceeds capacity planning, when a host is under attack (SYN flood followed by completion), or when connection timeouts are set too high causing connection table exhaustion.

Recommendation:

Check 'show service-policy' to identify which traffic class is hitting its limit and view current connection counts versus configured maximums. Use 'show conn count' to verify total active connections. If the limit is being reached during normal operations, consider increasing the conn-max value for the affected class or reducing connection idle timeouts to free resources faster. If a specific host is consuming excessive connections, investigate whether it is under attack or misconfigured. Review syslog 201011 messages to identify source and destination addresses repeatedly hitting the limit. In multi-context deployments, verify that per-context resource limits are appropriately allocated. Note that several historical defects caused incorrect connection accounting (negative counters, premature limit enforcement); if counters appear inconsistent with actual traffic, verify you are running a current software version.

Syslogs:

201011

----------------------------------------------------------------

tcp-data-past-fin

TCP data sent after FIN

The device received a TCP packet containing data from an endpoint that has already sent a FIN flag to close its side of the connection. According to TCP protocol rules, once an endpoint sends a FIN, it signals that it has no more data to send. Any subsequent data packets from that same endpoint violate the TCP state machine and are dropped by the TCP normalizer. This drop occurs when the connection is in half-closed state (one side has sent FIN) or closing state (both sides have sent FIN), and the device detects new data arriving with a sequence number at or beyond the FIN sequence. This typically indicates either a misbehaving TCP stack on the endpoint, packet reordering issues, or an application attempting to send data after initiating connection shutdown.

Recommendation:

Verify that the endpoint sending data after FIN is behaving correctly. Check for application bugs where the software attempts to send data after calling close() or shutdown(). If the issue occurs with specific applications or devices, contact the vendor to verify TCP stack compliance. Review packet captures on both sides of the device to determine if packet reordering or retransmissions are causing legitimate packets to appear out of sequence. If the drops are infrequent and do not impact application functionality, they may be benign—representing retransmissions of old data that arrived after the connection entered teardown. However, if applications are failing or connections are hanging, investigate the endpoint TCP implementation. Note that proper TCP state tracking depends on the device seeing all packets in the flow; asymmetric routing or packet loss can cause false positives.

Syslogs:

None

----------------------------------------------------------------

tcp-discarded-ooo

TCP packet discarded in TIMEWAIT state with unexpected sequence number

The device dropped a TCP packet that arrived during the TIMEWAIT state because the sequence or acknowledgment number did not match the expected values. TIMEWAIT is the final state after a TCP connection closes, where the device waits for delayed packets before fully releasing the connection. During this state, the device only accepts duplicate ACKs or retransmitted FIN-ACK packets with exact sequence number matches. Any packet with an out-of-order sequence number, including ACKs, FINs, or RSTs that do not match the tracked connection state, is discarded to prevent stale or malicious packets from interfering with the connection teardown process. This drop is a normal part of TCP state machine enforcement and typically occurs when delayed or retransmitted packets arrive after the connection has already transitioned to TIMEWAIT, or when an endpoint retransmits packets without proper sequence tracking.

Recommendation:

This counter incrementing is typically benign and indicates normal TCP state machine operation. The device is correctly rejecting packets that do not belong to the current connection state. However, if this counter increases rapidly or correlates with application connectivity issues, investigate the following: Check for network conditions causing excessive packet delay or reordering that might result in legitimate packets arriving after the connection enters TIMEWAIT. Review the TIMEWAIT timeout settings if connections are being closed and reopened rapidly with the same source/destination tuple. Examine packet captures to determine whether the out-of-order packets are legitimate retransmissions or potentially malicious traffic attempting to manipulate closed connections. If the drops affect legitimate traffic, consider whether the application is properly handling TCP connection teardown or if middleboxes in the path are modifying sequence numbers.

Syslogs:

None

----------------------------------------------------------------

tcp-dual-open

TCP simultaneous open not supported

This counter increments when the appliance receives a SYN packet from the server while a connection is in the embryonic state (SYN_RECV), indicating a TCP simultaneous open attempt. In simultaneous open, both endpoints send SYN packets to each other at nearly the same time, creating a connection without the traditional client-server handshake. The appliance does not support this rare TCP connection establishment method and drops the server-originated SYN packet. This scenario typically occurs when both hosts attempt to initiate a connection to each other using the same source and destination port pairs, which requires precise timing and is uncommon in normal network operations.

Recommendation:

This drop is expected behavior and indicates that an application or network condition attempted a simultaneous TCP open, which is not supported. Verify whether the traffic pattern is legitimate—simultaneous open is rarely used in modern applications. If the connection is needed, ensure one side acts as a clear client (initiating the SYN) and the other as a server (responding with SYN-ACK). If this counter increments frequently, investigate whether a misconfiguration is causing both endpoints to initiate connections simultaneously, or whether the traffic represents an unusual application behavior. No configuration change can enable simultaneous open support; the connection establishment must follow the standard three-way handshake.

Syslogs:

None

----------------------------------------------------------------

tcp-dup-in-queue

Duplicate TCP packet already in out-of-order queue

The firewall received a retransmitted TCP data packet that is already buffered in the out-of-order packet queue awaiting in-sequence processing. When TCP normalization is enabled with packet reordering (queue-limit configured in the tcp-map), the firewall buffers out-of-order packets to deliver them to inspection engines in the correct sequence. If the sender retransmits a packet before the firewall processes the original from the queue, the duplicate is detected by matching sequence number and dropped. This typically occurs during network congestion, packet loss, or aggressive retransmission timers on the sending host, where the sender assumes a packet was lost when it was actually queued for reordering.

Recommendation:

This counter is usually benign and indicates normal TCP retransmission behavior in environments with packet reordering. The firewall is correctly discarding redundant data. However, sustained or rapidly increasing counts may indicate: (1) Network path issues causing excessive packet reordering between the sender and firewall, prompting unnecessary retransmissions. (2) The sender's retransmission timer is too aggressive for the network conditions. (3) The firewall's out-of-order queue is holding packets longer than expected, possibly due to inspection delays or queue depth limits. Review the queue-limit setting in your tcp-map configuration—higher values allow more buffering but consume more memory; lower values reduce latency but may cause more drops if reordering is common. If drops correlate with application performance issues, capture packets on both sides of the firewall to determine whether reordering is occurring on the inbound path or if inspection processing is introducing delays.

Syslogs:

None

----------------------------------------------------------------

tcp-fo-drop

TCP control packet dropped during failover state learning

This counter increments when the device, operating in a high-availability pair, drops a TCP packet containing control flags (SYN, FIN, or RST) on an established connection during the failover transition period. When a standby unit becomes active, it must learn the state of existing TCP connections by observing live traffic—reconstructing sequence numbers, window sizes, and acknowledgment values from data packets. During this learning phase, the new active unit drops TCP control packets (SYN, FIN, RST) that arrive before the connection state is fully learned, because processing these packets without complete state information could corrupt the connection tracking. This is a transient condition that occurs immediately after failover while the new active unit is synchronizing connection state. The drops typically last only a few seconds until the device observes enough bidirectional traffic to establish accurate tracking for each connection.

Recommendation:

These drops are expected during the failover transition and do not indicate a problem. TCP endpoints will retransmit the dropped control packets, and once the new active unit has learned the connection state from observed data traffic, subsequent control packets will be processed normally. If you observe sustained tcp-fo-drop increments outside of a failover event, or if the counter continues to increment for more than a few seconds after failover completes, verify that failover state replication is functioning correctly using 'show failover' and 'show failover state'. Check that both units can exchange failover messages and that stateful failover is enabled if required. For connections that must maintain uninterrupted service during failover, ensure that stateful failover is configured and that the connection types are included in the replication policy (some protocols like HTTP are not replicated by default for performance reasons).

Syslogs:

None

----------------------------------------------------------------

tcp-global-buffer-full

TCP Global Out-of-Order Packet Buffer Full

This counter increments when the device receives an out-of-order TCP packet but cannot buffer it because the global memory pool for out-of-order packet reassembly is exhausted. The device maintains shared buffer pools (organized by packet size: 1550, 2048, and 9344 bytes) to temporarily hold out-of-order TCP segments across all connections. When these pools are full, newly arriving out-of-order packets are dropped and an acknowledgment is sent to the sender to trigger retransmission. This is a system-wide resource limit that protects the device from memory exhaustion when handling large volumes of out-of-order traffic. Out-of-order buffering occurs when TCP normalization is enabled and the device must reorder packets for stateful inspection, intrusion prevention, or application-layer processing. Common causes include asymmetric routing (where forward and return paths differ), network congestion, or upstream load balancing that distributes packets from the same flow across multiple paths.

Recommendation:

If this counter increments occasionally, it indicates temporary resource contention and is typically self-correcting through TCP retransmission. If the counter increments persistently, investigate the following: (1) Check for asymmetric routing in your network topology—use packet captures on both interfaces to confirm packets from the same flow are taking consistent paths. (2) Review the volume of concurrent connections and consider whether traffic patterns (such as large file transfers or high-bandwidth streaming) are causing sustained out-of-order delivery. (3) If intrusion prevention or deep packet inspection is enabled, verify whether specific traffic types (such as TLS connections) are disproportionately affected; in some cases, prefilter rules can bypass inspection for trusted traffic to reduce buffering requirements. (4) In cluster deployments, verify that flow director is properly distributing traffic and that cluster health is normal. If drops persist despite normal network conditions, contact Cisco TAC with output from 'show asp drop', 'show conn', 'show traffic', and packet captures from both interfaces showing the out-of-order behavior.

Syslogs:

None

----------------------------------------------------------------

tcp-invalid-ack

TCP Invalid ACK

The device received a TCP packet with an acknowledgement number that exceeds the amount of data sent by the peer endpoint. This indicates the packet is acknowledging data that was never transmitted, which violates TCP protocol semantics. This validation is part of TCP normalization and protects against certain TCP evasion techniques and malformed traffic. The counter increments when the ACK number in the received packet is greater than the next expected sequence number that the peer should be sending. This can occur due to network issues, misbehaving TCP stacks, asymmetric routing causing the device to see incomplete connection state, or during certain connection state transitions such as high-availability failover events.

Recommendation:

Review the traffic pattern to determine if drops are isolated or widespread. Occasional drops may indicate transient network issues or retransmissions and are typically benign. Persistent drops on specific connections suggest a problem with one endpoint's TCP implementation or asymmetric routing where the device cannot track the full connection state. If drops correlate with high-availability failover events, they may be expected during the brief state synchronization window. To allow these packets instead of dropping them, configure 'invalid-ack allow' in a TCP map and apply it to the affected traffic class. Alternatively, configure TCP state bypass for connections that do not require stateful inspection. If drops occur on half-open connections or during connection establishment, investigate whether SYN flood protection or connection limits are causing incomplete connection tracking.

Syslogs:

None

----------------------------------------------------------------

tcp-mss-exceeded

TCP data payload exceeded negotiated MSS

The appliance received a TCP packet whose data payload is larger than the Maximum Segment Size (MSS) that the receiving endpoint advertised during the three-way handshake. The MSS is negotiated when the connection is established and defines the maximum amount of TCP data (excluding headers) that each side is willing to accept in a single segment. This drop enforces RFC compliance and protects endpoints from receiving segments they declared they cannot handle. The violation typically indicates a misconfigured or misbehaving TCP stack on one of the endpoints, or in rare cases, intermediate devices (such as load balancers or proxies) that are modifying or fragmenting TCP segments incorrectly. The appliance tracks the negotiated MSS for each direction of the connection and validates every data packet against the appropriate limit.

Recommendation:

Review syslog message 419001 to identify which endpoint is sending oversized segments and the specific MSS limit being violated. Investigate the sending endpoint's TCP stack configuration, MTU settings, and any intermediate devices that might be modifying traffic. If the traffic is legitimate and the endpoints can actually handle the larger segments despite the advertised MSS (for example, due to path MTU discovery or jumbo frame support), you can disable this check by creating a tcp-map with the 'exceed-mss allow' command and applying it to the affected traffic via a service policy. However, allowing MSS violations may expose endpoints to segments they are not prepared to process. Before disabling the check, verify that both endpoints and the entire network path support the actual segment sizes being transmitted. If the violation is caused by a specific application or server, work with the application vendor or system administrator to correct the MSS advertisement or segment sizing behavior.

Syslogs:

419001

----------------------------------------------------------------

tcp-not-syn

First TCP packet not SYN

The firewall received a TCP packet (ACK, RST, FIN, or data packet) as the first packet of a new connection, without having seen the initial SYN handshake. This occurs when the firewall has no existing connection entry for the traffic and cannot establish proper TCP state tracking. Common legitimate causes include: asymmetric routing where the SYN packet took a different path that bypassed the firewall; the firewall previously closed the connection (timeout, administrative clear, or failover) but one or both endpoints continue transmitting; or mid-stream connection attempts. The counter may also increment after administrative actions such as 'clear local-host' or 'clear xlate' commands, when endpoints still believe connections are active. In cluster deployments, this can occur when packets arrive at a member that did not see the connection establishment, particularly with certain application inspections enabled (RTSP, SQL*Net). When TCP state bypass is configured alongside TLS server identity discovery or decryption policies, bypass-eligible traffic may incorrectly trigger this drop. Complex routing scenarios involving ECMP, policy-based routing, and VPN tunnels can also cause the SYN and subsequent packets to arrive at different firewall interfaces or cluster members.

Recommendation:

If the counter increments occasionally and connections work normally, this is typically benign—often caused by asymmetric routing or connection cleanup timing. If the counter increments rapidly or users report connection failures, investigate: (1) Check for asymmetric routing using packet captures on both interfaces to verify the firewall sees both directions of traffic, especially the initial SYN. (2) Review recent administrative actions—if drops correlate with 'clear conn', 'clear local-host', or 'clear xlate' commands, this is expected transient behavior. (3) In cluster deployments with application inspection (RTSP, SQL*Net, or others), verify that connection establishment packets reach the correct cluster member; consider disabling problematic inspections if they are not required. (4) If using TCP state bypass with TLS server identity discovery or TLS decryption policies, note these features are mutually exclusive—bypass traffic will be dropped; reconfigure to use only one feature. (5) For complex routing with ECMP, policy-based routing, or VPN tunnels, ensure routing is symmetric or configure the firewall to handle asymmetric flows appropriately. (6) If drops persist without clear cause and the counter increments rapidly, capture traffic on both interfaces to determine if this represents an attack (SYN flood evasion attempt) or a configuration issue. The associated syslog 106015 provides source/destination details for each drop.

Syslogs:

106015

----------------------------------------------------------------

tcp-paws-fail

TCP packet failed PAWS test

This counter increments when a TCP packet carrying a timestamp option is dropped because its timestamp value is older than the most recent timestamp seen on the connection. Protection Against Wrapped Sequences (PAWS), defined in RFC 1323, uses TCP timestamps to detect and reject stale or replayed segments that could corrupt the connection state. The device compares the incoming packet's timestamp against the last valid timestamp recorded for that direction of the flow. If the new timestamp is lower (indicating an older packet), and the connection has not been idle long enough to invalidate the cached timestamp, the packet is dropped and an acknowledgment is sent to the peer. This drop typically occurs in three scenarios: legitimate out-of-order delivery where very old retransmissions arrive after newer data has been acknowledged; network path changes that reorder packets significantly; or timestamp clock issues on the sending host. Long-lived connections (active for weeks) may also trigger this counter if timestamp values wrap around the 32-bit boundary, though this was addressed in ASA 9.8.1+ and 9.10.1+ releases. The check is bypassed for RST packets and for connections confirmed to be using WAN optimization (WAAS).

Recommendation:

Occasional increments are normal and indicate the device is correctly protecting against stale retransmissions. Investigate if the counter increases rapidly or correlates with application failures. First, verify the affected connection using 'show conn' and check for asymmetric routing or path instability that could cause severe packet reordering. For long-lived connections experiencing drops, confirm the software version includes the fix for timestamp wraparound (CSCuq80704) - upgrade to ASA 9.8.1 or later if needed. If drops persist and impact a specific application or traffic class, you can disable PAWS checking by clearing the timestamp option: create a tcp-map, configure 'tcp-options timestamp clear' within it, then apply the map to the affected traffic using 'set connection advanced-options' in a service policy. Note that clearing timestamps also disables round-trip time measurement and may reduce TCP performance on high-speed or high-latency links. If the application requires timestamps for performance but PAWS is causing false positives, contact Cisco TAC to investigate potential timestamp implementation issues on the endpoints.

Syslogs:

None

----------------------------------------------------------------

tcp-proxy-3whs-failed

TCP three-way handshake validation failed

The firewall dropped a TCP packet because it violated the expected three-way handshake sequence. This occurs when TCP normalization detects handshake anomalies such as: a SYN-ACK arriving from the wrong direction (client instead of server), a SYN-ACK with an acknowledgment number that does not match the client's initial sequence number, duplicate or out-of-sequence handshake packets, or unexpected TCP flags during connection establishment. TCP normalization is enabled by default and also activates automatically when certain application inspections are configured (such as SIP, H.323, RTSP, IM, DCERPC, SUNRPC, CTIQBE, or Skinny). This counter typically indicates asymmetric routing, packet replay, spoofing attempts, or timing issues where handshake packets arrive out of order.

Recommendation:

Examine the dropped connection details using 'packet-tracer' or 'capture' to identify which handshake packet was rejected and from which direction. Check for asymmetric routing where SYN and SYN-ACK traverse different paths through the firewall—this is the most common cause. If the traffic is legitimate but arrives out of order due to network conditions, consider whether the application can tolerate connection establishment delays or retries. In high-availability deployments, verify that connection state is properly synchronized between units. If the drops correlate with specific application inspection policies, review whether full TCP proxy mode is required for that traffic. For persistent issues with legitimate traffic, contact Cisco TAC with packet captures showing the complete three-way handshake sequence.

Syslogs:

None

----------------------------------------------------------------

tcp-proxy-copy-failed-drop

TCP full proxy packet copy failed due to memory exhaustion

This counter increments when the device is operating in TCP full proxy mode (used for deep inspection features like TLS decryption or intrusion prevention) and needs to duplicate a TCP control packet (RST, FIN, or ACK) to send to the inspection engine, but cannot allocate memory for the packet copy. In full proxy mode, the device terminates TCP connections on both sides and must forward control packets to the inspection engine for proper flow tracking, even though the local TCP stack will consume the original packet. When the system runs out of available packet buffers, this duplication fails and the connection is dropped. This typically occurs during memory exhaustion conditions when the device is processing high volumes of traffic or has insufficient memory resources available for packet buffering.

Recommendation:

Check memory utilization with 'show blocks' to identify packet buffer exhaustion. Look for blocks at or near their maximum allocation limit, or high FAILED counts in 'show blocks core' output. If specific block sizes show exhaustion, this indicates the device cannot allocate buffers for new packets. Review traffic patterns to identify whether high connection rates, large numbers of concurrent flows requiring deep inspection, or elephant flows are consuming buffer resources. Consider reducing the scope of deep inspection policies (TLS decryption, IPS) to fewer flows if memory pressure is consistent. On multi-core platforms, check for per-core block allocation imbalances. If memory exhaustion persists despite adequate physical memory, contact Cisco TAC as this may indicate a memory leak or resource management issue. This drop is not benign—it represents failed connections that required inspection.

Syslogs:

321007

----------------------------------------------------------------

tcp-proxy-fp-flow-null-drop

TCP proxy full proxy flow missing

This counter increments when a TCP packet arrives for full-proxy processing but the connection state has already been partially or fully torn down. Full-proxy mode is used when deep packet inspection is enabled, such as SSL/TLS decryption or advanced threat inspection. The device maintains paired flows (client-side and server-side) to terminate and proxy the TCP connection. This drop occurs when a packet arrives after one or both sides of the paired connection have been freed, typically during connection teardown or when transitioning between inspection modes. This can happen during normal connection cleanup when late-arriving packets reference flows that have already been removed, or during race conditions in high-traffic SSL decryption scenarios.

Recommendation:

Low, steady increments during normal traffic are expected and benign—they represent packets arriving after connections have legitimately closed. Investigate if you see rapid or sustained increases, especially with SSL/TLS decryption or TLS Server Identity Discovery enabled. Check for connection instability, application timeouts, or device resource exhaustion. If the counter grows rapidly alongside connection failures, review SSL decryption policies to ensure only necessary traffic is decrypted (use prefilter rules to limit scope). In rare cases, this may indicate a timing issue during flow cleanup; if accompanied by device reloads or tracebacks, contact Cisco TAC and reference any active advisories related to TCP proxy race conditions.

Syslogs:

852001 (Lightweight to Full Proxy transition), 852002 (Full Proxy to Lightweight transition)

----------------------------------------------------------------

tcp-proxy-fp2lw-enqueue-limit-drop

TCP proxy transition queue limit exceeded

This counter increments when the device drops a TCP packet during the transition from full proxy mode back to lightweight proxy mode because an internal receive queue has reached its limit. This transition occurs when deep packet inspection (such as SSL/TLS decryption or TLS Server Identity Discovery) determines that a connection no longer requires full inspection and can be handled more efficiently. During the transition, if the underlying TCP stack still has unprocessed input data, incoming packets are temporarily queued to maintain proper packet ordering. When this queue fills beyond its capacity, new packets are dropped. This typically occurs on connections with high packet rates, out-of-order packet arrival, or when the inspection engine takes longer than expected to complete the mode switch. The drop is a flow control mechanism to prevent memory exhaustion during the transition period.

Recommendation:

These drops are usually transient and self-correcting as the connection completes its transition to lightweight mode. If this counter increments frequently, investigate: (1) whether SSL/TLS policies are configured with 'Do Not Decrypt' actions that cause repeated mode transitions on active connections, (2) whether TLS Server Identity Discovery is enabled and causing transitions during high-volume traffic, (3) network conditions causing excessive out-of-order packet delivery, or (4) whether affected connections experience retransmissions or performance degradation. Review syslog messages 852001 and 852002 to identify which connections are transitioning between proxy modes. If drops correlate with application failures, consider using prefilter rules to bypass affected traffic from deep inspection, or adjust SSL/TLS policies to maintain consistent inspection depth throughout the connection lifetime.

Syslogs:

852001, 852002

----------------------------------------------------------------

tcp-proxy-invalid-tcp-checksum-drop

TCP proxy dropped packet with invalid checksum

The device is operating in full TCP proxy mode for deep inspection (typically for SSL/TLS decryption, certain application inspections like SIP, H.323, RTSP, or Diameter) and received a TCP RST or FIN packet carrying data with an invalid TCP checksum. When the device acts as a full TCP proxy, it terminates the TCP connection on both sides and must validate control packets before processing them. If hardware checksum offload did not already validate the packet, the device performs software checksum validation. Packets with RST or FIN flags that also carry payload data are subject to strict checksum validation because they signal connection teardown while potentially delivering final application data that requires inspection. This drop protects against corrupted or maliciously crafted packets that could bypass inspection or cause incorrect connection state transitions.

Recommendation:

This counter typically indicates one of three conditions: (1) Network path corruption—check for faulty NICs, cables, or intermediate devices that may be corrupting TCP checksums in transit. (2) Checksum offload misconfiguration—some virtualized environments or load balancers may forward packets with incorrect checksums; verify that upstream devices are not forwarding packets with invalid checksums. (3) Evasion attempts—attackers may craft invalid checksums to probe inspection behavior. If the counter increments steadily, capture packets on both sides of the device to determine whether checksums are valid on ingress. Review which flows are triggering full TCP proxy mode (check SSL decryption policies and application inspection configurations). If legitimate traffic is affected, verify that no intermediate devices are modifying packets without recalculating checksums. In most cases, this drop is protective and benign—it prevents the device from processing corrupted control packets that could lead to incorrect connection state.

Syslogs:

None

----------------------------------------------------------------

tcp-proxy-invalid-tcp-state-drop

TCP proxy invalid TCP state

This counter increments when a packet arrives for a connection that is transitioning from full TCP proxy mode back to lightweight proxy mode (bypass), but the internal TCP stack has already closed the connection. This occurs when the device is performing deep packet inspection (such as SSL/TLS decryption) and Snort signals that inspection is no longer needed. During this transition, if packets arrive with data, FIN, or RST flags while the underlying TCP control block is in the CLOSED state, they cannot be processed and are dropped. This typically happens due to timing issues during connection teardown, where packets arrive after the proxy's internal TCP stack has already closed but before the flow itself is fully torn down. The condition is most common on FTD devices with SSL decryption policies or other features requiring full TCP proxy mode.

Recommendation:

This drop is usually benign and occurs during normal connection teardown when packets arrive slightly out of sequence with the proxy state machine. If the counter increments occasionally, no action is needed. If you see sustained or high rates of this drop: (1) Verify that SSL/TLS decryption policies or other deep inspection features are configured correctly and not causing premature connection closure. (2) Check for asymmetric routing or network conditions causing significant packet reordering during connection teardown. (3) Review connection timeout settings if connections are being closed prematurely. (4) Use packet capture to examine the TCP sequence during teardown if drops correlate with application failures. Contact Cisco TAC if drops are associated with connection failures or application issues.

Syslogs:

852001, 852002

----------------------------------------------------------------

tcp-proxy-l2-copy-failed-drop

TCP Proxy L2 Header Decode Failed

This counter increments when the device is operating in full TCP proxy mode (typically for SSL/TLS decryption or deep packet inspection) and fails to decode a cached Layer 2 header during packet transmission. In full proxy mode, the device terminates both client and server TCP connections and reconstructs packets for transmission. To do this, it saves the Layer 2 header from the original ingress packet and prepends it to outbound packets. This drop occurs when the saved Layer 2 header cannot be decoded after being copied to an outbound packet, indicating the cached header is corrupted or contains an unsupported encapsulation format. This issue has been observed in environments using tunnel encapsulation such as AWS Gateway Load Balancer with Geneve tunnels, VxLAN, or other overlay network technologies where the Layer 2 frame structure may be complex or non-standard.

Recommendation:

This drop typically indicates a software defect or incompatibility between the TCP proxy implementation and the network encapsulation in use. Check if you are running SSL/TLS decryption policies in combination with tunnel interfaces (Geneve, VxLAN, VXLAN) or AWS Gateway Load Balancer deployments. If drops are occurring, verify you are running a current software version with fixes for TCP proxy and tunnel encapsulation issues. Review the configuration to ensure SSL decryption policies are supported on the interface types in use. If the issue persists, collect a packet capture showing the affected traffic, the output of 'show asp drop' and 'show conn detail' for affected connections, and contact Cisco TAC. This counter may indicate a defect requiring a software upgrade.

Syslogs:

None

----------------------------------------------------------------

tcp-proxy-l2-no-header-room

TCP proxy L2 no header room

This counter increments when the device drops an outbound TCP packet in full proxy mode because the packet buffer lacks sufficient space to prepend the saved Layer 2 header. Full proxy mode is used for features like SSL/TLS decryption that terminate and re-originate TCP connections. When sending packets back out, the proxy must reattach the original Layer 2 header (Ethernet, VLAN tags, tunnel encapsulation, etc.), but the packet buffer was allocated with insufficient headroom to accommodate the complete L2 header. This typically occurs with non-standard Layer 2 encapsulations such as Geneve tunnel interfaces, multiple VLAN tags, MPLS labels, or other encapsulation types that exceed the default Ethernet II header size assumed during buffer allocation.

Recommendation:

This drop indicates a buffer allocation issue in full proxy mode with non-standard Layer 2 encapsulation. Check if the traffic is traversing Geneve tunnel interfaces (common in AWS Gateway Load Balancer or Azure vWAN deployments) combined with SSL decryption or other full-proxy features. Review the interface configuration for complex Layer 2 encapsulation (stacked VLANs, MPLS, or tunnel headers). If drops occur consistently with specific interface types or encapsulation combinations, contact Cisco TAC with the output of 'show asp drop', 'show conn detail' for affected connections, 'show interface' for the egress interface, and 'show capture' if packet captures are available. This may indicate a platform-specific buffer sizing issue that requires a software fix.

Syslogs:

None

----------------------------------------------------------------

tcp-proxy-l2-not-initialized

TCP Proxy L2 Header Not Initialized

This counter increments when the device attempts to send a packet through the TCP full proxy but the Layer 2 header information required for packet reconstruction was not captured. The TCP proxy operates in two modes: lightweight proxy (minimal processing with sequence number adjustment) and full proxy (complete TCP termination for deep inspection). When a connection transitions from lightweight to full proxy mode—typically triggered by TLS/SSL decryption policies or Snort deep packet inspection—the system must reconstruct outbound packets with complete Layer 2 through Layer 4 headers. The Layer 2 header is normally captured from the first packet processed in lightweight mode and cached for later use. If the connection enters full proxy mode without this cached header information, outbound packets cannot be properly constructed and are dropped. This can occur during rapid connection establishment, when the proxy mode transition happens before sufficient packets have been processed, or in certain race conditions during policy application. The drop is silent with no corresponding syslog message.

Recommendation:

This counter typically indicates a transient condition during TCP proxy mode transitions. If the counter increments occasionally with no user-visible impact, no action is required—the client will retransmit and the connection will recover. If the counter increments frequently or correlates with connection failures, investigate the following: (1) Review SSL/TLS decryption policies to determine if aggressive full proxy transitions are occurring on initial packets before Layer 2 information can be captured. (2) Check for high rates of out-of-order packet arrival during connection establishment, which can disrupt the normal lightweight-to-full proxy transition sequence. (3) Verify that traffic patterns allow the device to process at least one packet in lightweight mode before transitioning to full proxy. (4) If the issue occurs with specific applications or traffic types, consider using prefilter rules to bypass Snort inspection for affected flows, allowing them to remain in lightweight proxy mode. If drops persist and impact production traffic, collect packet captures on both interfaces, 'show asp drop' output, and contact Cisco TAC for analysis.

Syslogs:

None

----------------------------------------------------------------

tcp-proxy-lw-ooo-drop

TCP proxy lightweight mode out-of-order packet drop

This counter increments when the firewall drops out-of-order TCP packets while operating in lightweight TCP proxy mode. Lightweight proxy mode is activated when traffic requires deep packet inspection, such as TLS Server Identity Discovery (TSID) or SSL decryption policies. The firewall maintains a temporary queue to reorder out-of-order packets before forwarding them to the inspection engine. Packets are dropped from this queue when: (1) the queue is disabled by configuration, (2) duplicate or retransmitted segments are detected, (3) packets contain older TCP timestamps than already-queued packets, (4) the per-connection queue exceeds its maximum entry limit, (5) global memory buffers for out-of-order queuing are exhausted, or (6) queued packets exceed the configured timeout period without being processed. This behavior is most commonly observed with fragmented TLS Client Hello messages (especially from Chrome 124+ browsers using large key shares), network paths with packet reordering, or high-throughput connections where packet arrival order varies.

Recommendation:

Review which traffic is being inspected with SSL/TLS policies or TSID and verify whether out-of-order packet arrival is expected on your network path. If drops correlate with connection failures or slowness, consider: (1) creating prefilter fastpath rules to bypass affected traffic from deep inspection if inspection is not required, (2) temporarily disabling TSID to determine if it is the trigger, (3) investigating upstream network devices for packet reordering issues, or (4) upgrading to a release containing fixes for known out-of-order handling defects (CSCwj82736, CSCwr85470). Occasional increments of this counter may be normal in environments with packet reordering and do not necessarily indicate a problem. Contact Cisco TAC if drops correlate with application failures and cannot be mitigated through policy adjustments.

Syslogs:

None

----------------------------------------------------------------

tcp-proxy-mixed-mode-drop

TCP Proxy Mixed Mode Transition Drop

This counter increments when packets are dropped during the transition from lightweight TCP proxy to full TCP proxy mode. When the inspection engine (Snort) determines that deeper inspection is required for a TCP connection, the device upgrades from lightweight proxy (which passes packets with minimal intervention) to full proxy (which terminates the TCP connection on both sides). During this transition, the connection enters a temporary 'mixed mode' state where one direction may still be using lightweight proxy while the other has moved to full proxy. Packets that were queued for transmission in lightweight mode must be cleared during this upgrade to maintain proper TCP state synchronization. This drop is part of normal proxy mode transition behavior and occurs on connections requiring deep packet inspection, such as SSL/TLS decryption, certain application inspections, or when Snort requests full proxy for policy enforcement. The counter typically appears on FTD devices with SSL decryption policies or deep inspection rules enabled.

Recommendation:

This counter incrementing is expected behavior during TCP proxy mode transitions and does not indicate a problem. It represents packets that were intentionally discarded as part of the state synchronization process when upgrading from lightweight to full proxy mode. No action is required unless the counter is incrementing at an unexpectedly high rate, which could indicate: (1) Inspection policies are triggering frequent proxy mode changes mid-connection rather than at connection setup, (2) Connections are being established in lightweight mode when they should start in full proxy mode. To minimize these drops, ensure that inspection policies requiring full proxy (SSL decryption, certain application inspections) are applied consistently at connection establishment. Review 'show conn detail' output to verify proxy mode assignments match your policy intent. If the counter increments excessively with no corresponding inspection policy changes, contact Cisco TAC for analysis.

Syslogs:

852001

----------------------------------------------------------------

tcp-proxy-mixed-mode-failed

TCP proxy mixed mode transition failed

This counter increments when the device cannot complete a TCP proxy mode transition for a connection undergoing deep inspection. The TCP proxy operates in two modes: lightweight mode (pass-through) and full proxy mode (terminates and re-originates the connection for deep inspection). When inspection policies such as SSL/TLS decryption require deeper analysis, the proxy transitions from lightweight to full mode. During this transition, the connection enters a temporary mixed mode where the two directions may operate in different proxy states, and data sent before the transition must be carefully synchronized. The drop occurs when the device encounters an error during this mixed-mode operation, typically due to one of three conditions: the internal connection state has been cleaned up (for example, when the inspection engine blacklists the flow immediately before packet processing), the peer side of the connection has timed out and requires a reset, or the device cannot allocate memory to retransmit data that was sent before the proxy was established. This is most commonly seen on FTD platforms with SSL/TLS inspection, encrypted visibility, or identity policies that trigger mid-connection proxy activation.

Recommendation:

This drop is typically transient and indicates the device is protecting itself from processing packets on connections that are being torn down or have encountered resource constraints. If the counter increments occasionally, no action is required—the client will retransmit and establish a new connection. If the counter increments frequently, investigate the following: check for high rates of connection blacklisting or blocking by the inspection engine (review Snort block events and intrusion policies); verify memory availability using 'show memory' and 'show blocks'—sustained memory pressure can prevent buffer allocation during mode transitions; review SSL/TLS decryption policies to ensure they are not triggering excessive proxy transitions on short-lived connections; and examine 'show conn detail' to identify connections stuck in transitional states. If drops correlate with device reloads or high CPU, contact Cisco TAC with 'show asp drop', 'show memory', 'show conn detail', and a packet capture of affected traffic.

Syslogs:

852001, 852002

----------------------------------------------------------------

tcp-proxy-no-inspection

TCP proxy unable to send packet for inspection

This counter increments when the TCP proxy subsystem cannot forward a packet to the threat detection engine for deep packet inspection. The TCP proxy is used on FTD devices when certain features require full or lightweight connection proxying, such as TLS/SSL decryption, intrusion prevention policies, or application-layer protocol inspection. The drop occurs when the proxy encounters an internal error that prevents it from queuing or dispatching the packet to the inspection engine. Common triggers include flow state inconsistencies (missing or invalid flow context, missing paired flow for bidirectional proxy), proxy structure corruption, or resource exhaustion during inspection handoff. This drop is distinct from inspection policy decisions—it represents an infrastructure failure in the proxy-to-inspector communication path rather than a security verdict.

Recommendation:

Check for related TCP proxy error counters using 'show asp drop' and filter for other tcp-proxy drops. Review 'show conn detail' to identify affected connections and verify whether they show expected proxy state. If drops correlate with high traffic load, investigate memory pressure using 'show memory' and 'show blocks'. For persistent issues, examine whether specific traffic patterns (particular applications, TLS versions, or connection rates) trigger the drops. If drops occur during policy changes or Snort restarts, they may be transient and self-correcting. Sustained or growing counters indicate a software defect or resource exhaustion condition—collect 'show tech-support' and contact Cisco TAC, as this typically requires engineering analysis of the proxy and inspection subsystem interaction.

Syslogs:

None typically associated. Related informational messages may appear: %FTD-6-852001 (lightweight to full proxy transition) or %FTD-6-852002 (full proxy to lightweight transition).

----------------------------------------------------------------

tcp-proxy-null-flow-drop

TCP proxy received packet for missing flow

This counter increments when the device receives a TCP packet that requires proxy processing (typically for SSL/TLS decryption or deep inspection), but the internal flow state needed to process the packet no longer exists. This occurs when packets arrive after the connection has been torn down or during race conditions between flow cleanup and packet arrival. The device is operating as a TCP proxy to decrypt and inspect encrypted traffic, and packets are being exchanged between the inspection engine and the network stack. When a packet arrives but the flow context has already been freed—either because the connection closed, timed out, or was reset—the packet cannot be processed and is dropped. This is most commonly seen with SSL/TLS decryption policies where the device terminates both client and server TCP connections to inspect encrypted traffic. The condition can occur during normal connection teardown when late-arriving packets reference flows that have already been cleaned up, or in high-load scenarios where timing windows between flow deletion and packet processing overlap.

Recommendation:

This drop is typically benign and represents normal cleanup behavior during connection teardown, especially for SSL/TLS decrypted traffic. Occasional increments are expected in environments using decrypt-resign or decrypt-known-key policies. If the counter is incrementing rapidly or affecting user traffic, verify that SSL decryption policies are applied only to necessary traffic using prefilter rules to reduce load on the TCP proxy subsystem. Check for abnormal connection reset patterns or timeout issues that might cause premature flow cleanup. Review 'show conn detail' output to confirm TCP proxy state for active connections. If the issue correlates with a device reload or traceback, check for known defects related to TCP proxy race conditions (such as CSCwm80732) and ensure the software version includes relevant fixes. Contact Cisco TAC if drops are accompanied by service impact or if the rate suggests a systemic issue rather than normal teardown behavior.

Syslogs:

None

----------------------------------------------------------------

tcp-proxy-ooo-drop

TCP Proxy Passive Mode Out-of-Order Drop

The firewall dropped a TCP packet that arrived out of sequence while operating in passive TCP proxy mode. Passive mode is used when the firewall monitors traffic on tap or passive interfaces without fully terminating TCP connections. Unlike full proxy mode, passive mode tracks expected sequence numbers but does not buffer or reorder out-of-sequence packets. When a packet arrives with a sequence number higher than expected, it is dropped because the passive proxy cannot queue packets for later processing. This typically occurs during TLS handshakes when Client Hello or Server Hello messages are fragmented across multiple packets and arrive out of order, or when network conditions cause packet reordering on monitored traffic.

Recommendation:

This counter is expected to increment in passive monitoring scenarios where the firewall observes but does not control packet delivery order. If you see this counter incrementing on production traffic (not tap/passive interfaces), verify that TLS Server Identity Discovery or SSL inspection policies are not inadvertently placing connections into passive proxy mode. For tap or passive interface monitoring, these drops are normal and do not affect actual traffic flow since the firewall is only observing copies of packets. If the counter increments on active interfaces with TLS inspection enabled, check for network conditions causing excessive packet reordering, review TLS Server Identity Discovery configuration, or consider using prefilter rules to bypass affected traffic from deep inspection if connection failures occur.

Syslogs:

None

----------------------------------------------------------------

tcp-proxy-probe-blk-alloc-failed

Memory allocation failure during TLS probe connection retry

This counter increments when the device cannot allocate memory to retry a TLS server certificate probe connection after detecting a source port collision. During TLS/SSL decryption with Server Identity Discovery enabled, the device probes destination servers to retrieve their certificates when not already cached. The probe connection uses a randomly selected source port from a configured range. If that port is already in use (collision), the system attempts to allocate a new packet buffer to retry with a different port. This counter fires when that memory allocation fails, preventing the retry attempt. The device will attempt up to 5 retries by default before abandoning the probe. This drop indicates memory pressure on the system during active TLS inspection operations.

Recommendation:

This counter typically indicates memory resource exhaustion during periods of high TLS inspection activity. Check overall system memory utilization with 'show memory' and 'show blocks'. If memory is consistently low, consider: reducing the number of concurrent TLS inspection sessions, increasing system memory if supported, or adjusting TLS Server Identity Discovery settings to reduce probe frequency. Review 'show asp drop' for other memory-related drops occurring simultaneously. If this counter increments frequently without corresponding memory pressure, contact Cisco TAC for further investigation. Note that occasional increments during traffic spikes may be normal and self-correcting.

Syslogs:

None

----------------------------------------------------------------

tcp-proxy-probe-client-conn-collision

Client packet matches TLS certificate probe connection

This counter increments when a packet from the original client arrives on a connection that has been designated as a TLS certificate probe connection. During TLS decryption with hardware offload, the system may establish a separate probe connection to the server to retrieve the TLS certificate before processing the actual client connection. This probe connection uses synthetic packets with specific connection parameters. If a real packet from the client arrives with the same source IP, source port, destination IP, and destination port as the probe connection, it creates a tuple collision. The packet is dropped because the connection is reserved for the probe operation and cannot simultaneously handle real client traffic. This typically occurs due to timing issues where the client retransmits or sends additional packets while the certificate probe is still active, or when port reuse causes the same 5-tuple to be selected for both the probe and a legitimate client connection.

Recommendation:

This drop is usually transient and self-correcting. The client will retransmit, and once the certificate probe completes, subsequent packets will be processed normally on a new connection. If this counter increments frequently, investigate: (1) whether clients are experiencing high retransmission rates that cause packets to arrive during the probe window, (2) whether the probe timeout configuration is too long, causing extended collision windows, or (3) whether there is insufficient entropy in source port selection leading to tuple reuse. Check TLS decryption policy configuration and consider reviewing 'show conn detail' for probe connections (marked with [Probe] in syslog 302013/302014). If the counter grows continuously for specific clients or servers, collect packet captures and contact Cisco TAC, as this may indicate a timing or state synchronization issue in the TLS offload path.

Syslogs:

302013, 302014

----------------------------------------------------------------

tcp-proxy-probe-fin-ack-rcv

Final ACK received during TLS probe connection teardown

This counter increments when the firewall receives the final ACK packet during the normal teardown of a TLS Server Identity Discovery probe connection. When TLS Server Identity Discovery is enabled and a server's certificate is not in the cache, the firewall initiates a temporary probe connection to retrieve the certificate. After the certificate is obtained, the probe connection closes using a standard TCP teardown sequence (FIN, FIN-ACK, ACK). This counter tracks the final ACK in that sequence, which is dropped because the probe connection has served its purpose and is being cleaned up. This is expected, benign behavior that occurs during normal TLS Server Identity Discovery operation.

Recommendation:

No action required. This counter reflects normal operation of the TLS Server Identity Discovery feature. The probe connection is a temporary, internal mechanism used to retrieve and cache server certificates for policy evaluation. If you see this counter incrementing, it indicates that TLS Server Identity Discovery is actively probing servers to populate the certificate cache. You should also see corresponding syslog 302014 messages showing probe TCP connection teardowns. If TLS Server Identity Discovery is not intentionally configured or if you experience connection issues, verify your SSL/TLS decryption policy settings in FMC.

Syslogs:

302014

----------------------------------------------------------------

tcp-proxy-probe-inject-pkt

TLS server certificate probe packet re-injected due to port collision

This counter increments when the device drops a TLS server certificate probe packet in order to re-inject it with a different source port. This occurs during TLS Server Identity Discovery (TSID), a feature that proactively retrieves server certificates to make decryption policy decisions before the actual client connection completes. When the device initiates a probe connection to fetch the server's certificate, it randomly selects a source port from a configured range. If that port is already in use (a collision), the device drops the original probe packet and immediately re-injects it with a newly randomized source port. The system will retry up to a configurable maximum (default 5 attempts) before giving up. This drop is part of normal probe connection handling and does not indicate a problem with user traffic—the original client connection is unaffected while the probe connection is being established in parallel.

Recommendation:

This counter incrementing is expected behavior when TLS Server Identity Discovery is enabled and indicates the device is actively managing probe connection source port conflicts. No action is required unless the counter grows rapidly, which could indicate port exhaustion in the probe port range. If you observe high values, verify that the probe source port range (configurable via platform settings) is sufficiently large for your connection rate. The feature is typically enabled on FTD devices performing SSL/TLS decryption. If probe connections are consistently failing (check for corresponding timeout or max-collision counters), review network connectivity between the device and destination servers, and ensure the probe source interface has proper routing and NAT configuration.

Syslogs:

302013 (Built [Probe]TCP connection), 302014 (Teardown [Probe]TCP connection)

----------------------------------------------------------------

tcp-proxy-probe-invalid-tcp

Certificate Visibility Probe Connection State Error During FIN Processing

This counter increments when the firewall receives a connection termination (FIN) from a server during a certificate visibility probe, but the internal connection state is missing or invalid. Certificate visibility probes are temporary connections the firewall initiates to retrieve server certificates when inspecting TLS 1.3 traffic, where certificates are encrypted in the handshake. The firewall creates a separate TLS 1.2 connection to the server to obtain the certificate for policy matching, then tears down this probe connection. This drop indicates an internal inconsistency where the probe connection was configured for full connection tracking, but the required state structure is absent when attempting to process the server's FIN packet. This typically occurs during the probe connection teardown phase and represents an unexpected internal condition rather than a configuration or traffic issue.

Recommendation:

This counter usually indicates a transient internal state issue during TLS 1.3 certificate visibility operations. The actual user connections should not be affected, as this drop applies only to the temporary probe connections used for certificate retrieval. If this counter is incrementing frequently, verify that TLS decryption policies are correctly configured and that the firewall has sufficient resources (CPU and memory). Check for any patterns correlating with specific destination servers or certificate types. If the counter grows rapidly or user-visible TLS connection failures occur, collect 'show asp drop', 'show conn detail' output filtered for Probe connections, and 'show tls-proxy' statistics, then contact Cisco TAC for analysis. In most cases, occasional increments of this counter during normal TLS 1.3 inspection operations are not cause for concern, as the probe mechanism includes retry logic and the user's actual connection proceeds independently.

Syslogs:

302014 (Probe TCP connection teardown)

----------------------------------------------------------------

tcp-proxy-probe-lock-fin-fail

TCP Proxy Probe Lock Failure During FIN Processing

This counter increments when the device drops a FIN packet during the teardown of a TCP proxy probe connection used for TLS/SSL decryption. Probe connections are temporary connections that the device establishes to retrieve and validate server certificates before deciding whether to decrypt traffic. The drop occurs specifically when the device operates in full-proxy mode and cannot acquire the internal lock needed to update connection state during the FIN handshake. This is typically caused by a race condition where the connection is being torn down while another process is accessing the same connection state. The issue is most commonly seen on platforms performing SSL/TLS decryption with decrypt-resign or decrypt-known-key policies applied to HTTPS traffic.

Recommendation:

This drop is usually transient and self-correcting—the probe connection will be retried or cleaned up through timeout mechanisms. If you see sustained or high counts of this drop, it may indicate resource contention during SSL decryption operations. To reduce the frequency: (1) Use prefilter rules to limit which traffic undergoes SSL decryption, focusing only on traffic that requires deep inspection. (2) Review SSL decryption policies to ensure they are not applied too broadly to high-volume traffic. (3) Check for related defects, particularly CSCwm80732, which addresses a race condition in TCP proxy during SSL decryption that can cause this drop and, in severe cases, device reloads. If drops persist at high rates or correlate with connection failures, collect 'show asp drop', 'show conn detail', and 'show snort tls-offload' output and contact Cisco TAC.

Syslogs:

302014 (Probe TCP connection teardown)

----------------------------------------------------------------

tcp-proxy-probe-max-port-collision

SSL decryption server certificate probe exhausted port collision retries

This counter increments when SSL/TLS decryption is enabled and the device attempts to probe the destination server to retrieve its certificate for inspection, but cannot establish the probe connection after multiple attempts due to source port collisions. During SSL decryption operations, the device initiates probe connections to servers using randomly selected source ports from a configured range. If the randomly chosen port is already in use by another connection (a port collision), the system retries with a different random port. When the maximum number of retry attempts (default: 5) is exhausted without finding an available port, the probe connection is dropped and this counter increments. This typically occurs in high-connection-density environments where the available source port range is constrained or when many simultaneous SSL decryption operations are active. The original client connection may be affected if the certificate cannot be retrieved for policy evaluation.

Recommendation:

This counter indicates source port exhaustion during SSL decryption probe operations. If this counter is incrementing: (1) Verify the configured TCP proxy probe source port range is adequate for your traffic volume—check the current range with 'show running-config' and look for TCP proxy probe port configuration; (2) Consider expanding the source port range if it is narrowly configured; (3) Review the number of concurrent SSL decryption sessions and connections—use 'show conn' and 'show asp drop' to correlate with other SSL-related drops; (4) Check if NAT or PAT is further constraining available source ports for probe connections; (5) Monitor overall connection table utilization with 'show conn count'—if approaching limits, this may contribute to port exhaustion. If the counter increments rarely, it may be benign and represent transient port conflicts. Sustained or frequent increments suggest insufficient port resources for SSL decryption probe operations. Contact Cisco TAC if expanding the port range does not resolve the issue or if SSL decryption is failing for legitimate traffic.

Syslogs:

None

----------------------------------------------------------------

tcp-proxy-probe-rst-injected

TLS certificate probe connection terminated by inspection engine

This counter increments when the inspection engine injects a reset packet to terminate a TLS Server Identity Discovery probe connection after successfully retrieving the server certificate. When TLS Server Identity Discovery is enabled, the device creates temporary probe connections to servers to obtain their TLS certificates for caching. Once the server hello and certificate are received, the inspection engine injects a reset to cleanly close the probe connection. This is normal, expected behavior during certificate discovery operations and does not indicate a problem with user traffic.

Recommendation:

No action required. This counter reflects normal operation of the TLS Server Identity Discovery feature. The probe connections are internal to the device and do not affect user connections. If you observe unexpectedly high values, verify that TLS Server Identity Discovery is configured as intended in your SSL/TLS decryption policy. If you experience connection issues with TLS Server Identity Discovery enabled, check for related counters or consider temporarily disabling the feature to isolate the issue.

Syslogs:

None

----------------------------------------------------------------

tcp-proxy-probe-server-fin

Certificate visibility probe received server FIN

This counter increments when the firewall receives a FIN packet from the destination server during a TLS certificate visibility probe connection. Certificate visibility probes are temporary connections initiated by the firewall to retrieve server certificates for TLS 1.3 traffic, where the certificate is encrypted in the normal handshake. The firewall establishes a separate probe connection to the server (using TLS 1.2 to obtain the unencrypted certificate), then uses that certificate information to match SSL decryption policies for the actual client connection. When the server sends a FIN to close the probe connection, the firewall drops the FIN packet (after responding with FIN-ACK to complete the graceful shutdown) and increments this counter. This is normal, expected behavior during certificate visibility operations.

Recommendation:

This counter incrementing is normal and does not indicate a problem. It reflects the standard teardown of certificate visibility probe connections after the firewall has successfully retrieved the server certificate. These probe connections are short-lived by design—the firewall initiates them solely to obtain certificate information for policy matching, then closes them. You will see this counter increment on FTD platforms with SSL decryption policies configured and certificate visibility enabled (the default for TLS 1.3 traffic). If you see a high rate of these drops, it indicates active TLS 1.3 connections requiring certificate visibility probes, which is expected behavior. No action is required unless you observe SSL decryption policy failures or connection issues, in which case review the SSL policy configuration and check 'show asp table socket' for probe connection details.

Syslogs:

302013, 302014 (probe connection build/teardown)

----------------------------------------------------------------

tcp-proxy-probe-server-rst

Server sent RST to TLS Server Identity Discovery probe connection

The firewall dropped a TCP RST packet received from the server in response to a TLS Server Identity Discovery (TSID) probe connection. When TSID is enabled in a decryption policy, the firewall may initiate a separate probe connection to the destination server to retrieve its TLS certificate before allowing the original client connection to proceed. If the server rejects this probe attempt with a TCP RST (for example, due to rate limiting, connection limits, or security policies that detect the probe behavior), this counter increments. The RST packet itself is dropped as part of normal probe connection cleanup. The original client connection may be affected depending on whether the certificate was successfully retrieved before the RST occurred. This behavior is most commonly seen with FTP over TLS (FTPS) data channels, application servers with strict connection policies, or servers that detect and reject the probe handshake pattern.

Recommendation:

This counter typically indicates normal operation when servers reject probe connections, but high values may point to compatibility issues with TLS Server Identity Discovery. Check whether the affected traffic requires TSID—if the destination servers or applications are experiencing connection failures or slowdowns, consider these actions: (1) Review the decryption policy to confirm TSID is necessary for the affected traffic; (2) If TSID is not required, disable the 'TLS Server Identity Discovery' option in the SSL/TLS decryption policy advanced settings; (3) For traffic that must bypass TSID (such as FTPS data channels or applications incompatible with probe connections), create prefilter rules to bypass Snort inspection for those flows; (4) Monitor syslog 302014 messages with the '[Probe]' prefix to identify which servers are rejecting probe connections; (5) If legitimate traffic is being disrupted and TSID must remain enabled, contact Cisco TAC for guidance on tuning or excluding specific traffic patterns.

Syslogs:

302014 (when probe connection tears down)

----------------------------------------------------------------

tcp-proxy-probe-tcp-probe-drop

TLS certificate probe response received

This counter increments when the firewall receives and processes response packets from a server during a TLS certificate discovery probe connection. When TLS 1.3 decryption is enabled with Certificate Visibility (also called TLS Server Identity Discovery), the firewall creates temporary probe connections to servers to retrieve their certificates before the encrypted handshake completes. These probe connections use TLS 1.2 to obtain the server certificate in cleartext, which is then cached for policy matching. Response packets from the server on these probe connections (SYN-ACK, Server Hello, certificate data, FIN, and final ACK) are consumed by the probe mechanism and dropped after processing - they are never forwarded to the original client. This counter reflects normal operation of the certificate discovery feature and indicates successful communication with the destination server during the probing process.

Recommendation:

No action required. This counter indicates normal operation when TLS 1.3 decryption with Certificate Visibility is configured. Each increment represents a packet received from a server in response to a certificate probe, which is expected behavior. The probe connection runs in parallel with (or slightly before) the actual client connection and allows the firewall to make decryption policy decisions based on server certificate attributes even when TLS 1.3 encrypts the certificate. If you see this counter incrementing, it confirms that certificate probing is working correctly. If TLS decryption is not configured or Certificate Visibility is not enabled, this counter should remain at zero. High values are normal in environments with many TLS 1.3 connections to new or uncached servers.

Syslogs:

302013 (Built [Probe] TCP connection), 302014 (Teardown [Probe] TCP connection)

----------------------------------------------------------------

tcp-proxy-retransmit-drop

TCP proxy retransmit during inspection

The firewall dropped a retransmitted TCP packet because the original packet is still queued for deep packet inspection. This occurs when the device is operating in full TCP proxy mode for certain application inspections (such as RTSP, SIP, H.323, DCERPC, or Snort/TLS Server Identity Discovery) and the sender retransmits data before the inspection engine has finished processing the original packet from its receive queue. The retransmission is dropped to prevent duplicate data from being inspected or forwarded, which could cause application-layer protocol errors. This typically happens during periods of high inspection load, when transitioning between full-proxy and lightweight-proxy modes, or when out-of-order packets arrive during TLS handshake inspection.

Recommendation:

Occasional increments are normal and indicate the TCP retransmission mechanism is working correctly—the sender will continue retransmitting until the firewall completes inspection and acknowledges the data. Sustained or rapidly increasing counters may indicate inspection performance issues. Check for high CPU utilization on the Snort inspection engine (use 'show cpu' and 'show snort statistics'). If TLS Server Identity Discovery is enabled and you observe connection slowness, consider disabling TSID or using pre-filter rules to bypass affected traffic from deep inspection. For connections using application inspections that require full TCP proxy (RTSP, SIP, H.323), verify that inspection policies are not overly complex and consider tuning TCP proxy queue limits if available. If drops correlate with connection failures, collect packet captures on both interfaces and contact Cisco TAC.

Syslogs:

None

----------------------------------------------------------------

tcp-reserved-set

TCP Reserved Bits Set

The device received a TCP packet with one or more reserved bits set in the TCP header and dropped it because a policy is configured to enforce strict TCP header compliance. Reserved bits are undefined fields in the TCP header (between the data offset and control flags) that must be zero according to RFC 793. By default, the device allows packets with reserved bits set to pass through without modification. This drop only occurs when a TCP normalization policy (tcp-map) is explicitly configured with the 'reserved-bits drop' option and applied to the traffic via a service policy. Reserved bits are sometimes set by non-compliant TCP stacks, by attackers attempting to evade detection, or rarely by packet corruption.

Recommendation:

Verify whether the drop is expected based on your security policy. If you have configured 'reserved-bits drop' in a tcp-map and want to enforce strict RFC compliance, these drops are working as designed. Use packet capture to examine the dropped packets and identify the source. If the traffic is legitimate but the sending device sets reserved bits, you have three options: (1) change the tcp-map configuration to 'reserved-bits allow' to permit the packets unchanged, (2) use 'reserved-bits clear' to strip the reserved bits and forward the packets, or (3) exclude the affected traffic from the tcp-map policy. If you have not intentionally configured reserved-bits enforcement but are seeing these drops, verify your tcp-map configuration—in rare cases, other tcp-map options may interact unexpectedly (see defect CSCus18940 for a historical example involving timestamp clearing).

Syslogs:

None

----------------------------------------------------------------

tcp-rst-syn-in-win

TCP RST/SYN in window

The firewall received a TCP SYN or RST packet on an already-established connection. The sequence number was within the valid TCP window but was not the next expected sequence number for that direction of the flow. This is a security protection against TCP connection hijacking and spoofing attacks, where an attacker attempts to inject control packets with plausible (but incorrect) sequence numbers to disrupt or take over an active connection. The firewall drops the suspicious packet and sends an acknowledgment back to help legitimate endpoints resynchronize if needed. This drop can occur during normal operation when network issues cause duplicate SYN packets to arrive after a connection is established, when asymmetric routing causes the firewall to see packets out of order, or during actual attack attempts. The TCP normalizer validates that control packets (SYN/RST) on established connections have the exact expected sequence number, not just any in-window value.

Recommendation:

Review the connection details to determine if this is expected behavior or indicates a problem. Small, occasional increments are typically benign and result from network retransmissions or timing issues during connection setup. Sustained or high-rate increments may indicate TCP spoofing attacks, asymmetric routing where the firewall sees only one direction of traffic, or applications that improperly reuse connection tuples. Use packet captures to examine the sequence numbers of dropped packets and compare them to the connection state. If the drops correlate with connection failures, investigate routing symmetry and ensure the firewall sees both directions of each TCP flow. For persistent issues with legitimate traffic, verify that no middleboxes (load balancers, proxies, WAN optimizers) are modifying TCP sequence numbers. This counter is part of the TCP normalizer security features and cannot be disabled; it protects against a class of TCP-based attacks.

Syslogs:

None

----------------------------------------------------------------

tcp-rstfin-ooo

TCP RST or FIN with sequence number outside window

The device drops TCP reset (RST) or connection termination (FIN) packets when their sequence number falls outside the expected receive window for the connection. This is a security check performed by TCP normalization to prevent malicious or spoofed termination packets from disrupting legitimate connections. The receive window is calculated based on the last acknowledged sequence number plus the advertised window size (with scaling applied). Legitimate RST or FIN packets should arrive with sequence numbers within this window. This drop can occur when network conditions cause significant packet reordering, when RST packets are generated by intermediate devices with stale connection state, or during VPN tunnel scenarios where encapsulation and decapsulation introduce timing variations. High connection rates or asymmetric routing can also trigger this condition. Connections using WAAS optimization are exempt from this check.

Recommendation:

This counter typically indicates either a security event (spoofed termination packets) or a network condition causing severe packet reordering. First, determine if the drops correlate with connection failures or are benign. Check for: (1) asymmetric routing or path changes that could cause packets to arrive out of order, (2) VPN tunnels where encapsulation overhead or queuing might reorder packets, (3) intermediate devices (load balancers, proxies) sending RST packets with incorrect sequence numbers, (4) very high connection rates that stress connection tracking. If drops are causing legitimate connection termination failures and you've ruled out security concerns, consider enabling tcp-state-bypass for affected traffic classes, though this reduces security protections. For VPN scenarios, verify that both peers have consistent connection state. If drops occur during normal operation without user impact, they may represent blocked attack attempts and can be ignored. Capture packets on both interfaces during drops to determine if sequence numbers are genuinely invalid or if timing issues are causing legitimate packets to appear out of window.

Syslogs:

None

----------------------------------------------------------------

tcp-seq-past-win

TCP packet sequence number past window

The device received a TCP data packet whose sequence number exceeds the right edge of the receive window advertised by the peer endpoint. This indicates the sender is transmitting data beyond what the receiver has agreed to accept. The packet is dropped and an acknowledgment is sent to the peer to help resynchronize the connection. This drop occurs only when TCP normalization is configured to enforce strict sequence number validation (via the 'seq-past-window drop' command in a tcp-map policy). By default, such packets are allowed. Common triggers include: network packet reordering or delay causing legitimate packets to arrive after the window has advanced; asymmetric routing where the device sees only one direction of traffic and cannot accurately track window state; or TCP state desynchronization after high-availability failover. On FTD platforms with deep packet inspection enabled, this counter may increment when acknowledgment packets are delayed through the inspection engine while later acknowledgments bypass inspection and update window state first, causing legitimate data packets to appear out-of-window.

Recommendation:

Review whether strict sequence validation is required for the affected traffic. If the counter increments frequently, verify that the device sees bidirectional traffic for the connection—asymmetric routing will cause false positives. Check for network conditions causing significant packet delay or reordering. On FTD platforms, if the issue correlates with inspection-enabled traffic and acknowledgment passthrough is active (default on most platforms), consider temporarily disabling 'asp inspect-dp ack-passthrough' to test whether inspection timing is contributing to the drops. For traffic that does not require strict TCP normalization, apply a tcp-map with 'seq-past-window allow' or bypass normalization entirely using prefilter fastpath rules. If drops persist and cause application failures, collect packet captures on both interfaces to determine whether sequence numbers are legitimately out-of-window or if the device's window tracking is incorrect. Contact Cisco TAC if drops occur without corresponding network issues, especially after software upgrades or failover events.

Syslogs:

None

----------------------------------------------------------------

tcp-seq-syn-diff

Duplicate SYN or SYN-ACK with Different Sequence Number

The firewall drops a duplicate SYN or SYN-ACK packet received during the TCP three-way handshake when the packet carries a different initial sequence number than the original packet that started the connection. This occurs when the firewall has already recorded the initial sequence number from the first SYN or SYN-ACK, and a subsequent packet with the same source/destination addresses and ports arrives with a mismatched sequence number before the handshake completes. Common causes include routing loops (where packets circle back through the firewall), network misconfigurations causing duplicate packet delivery, or potential spoofing attacks. In some cases, this may also occur with legitimate traffic when load balancers or other network devices retransmit connection attempts with different sequence numbers.

Recommendation:

Check for routing loops or misconfigurations in the network topology that could cause the same SYN packet to traverse the firewall multiple times. Review routing tables on the firewall and adjacent devices. Examine packet captures to determine whether the duplicate packets are arriving from the same or different source MAC addresses, which can help distinguish between routing issues and spoofing attempts. If the counter increments at a high rate and is accompanied by syslog message 419002, investigate whether a routing loop or denial-of-service condition exists, as excessive occurrences can impact firewall CPU and performance. In most cases, the drops are protective and no action is needed unless legitimate connections are failing to establish.

Syslogs:

419002

----------------------------------------------------------------

tcp-syn-data

TCP SYN with data

The firewall received a TCP SYN packet that contains a data payload and dropped it because TCP normalization is configured to reject this behavior. By default, the appliance blocks SYN packets carrying data as a security measure against certain evasion techniques and malformed connection attempts. However, TCP Fast Open (RFC 7413) is a legitimate protocol extension used by modern applications to reduce connection latency by sending initial request data in the SYN packet. If your environment uses TCP Fast Open—common with web services, CDNs, and latency-sensitive applications—this counter will increment for every blocked connection attempt, preventing those connections from establishing.

Recommendation:

If this counter is incrementing and you are experiencing connection failures to services that use TCP Fast Open, you must explicitly allow SYN packets with data. Create or modify a TCP map with the 'syn-data allow' command, then apply it to the affected traffic using a service policy. Example: 'tcp-map ALLOW_TFO' / 'syn-data allow' / apply via class-map and policy-map with 'set connection advanced-options ALLOW_TFO'. If you are not using TCP Fast Open and this counter is incrementing, investigate whether the traffic is legitimate (check source/destination and application) or represents an attack or misconfiguration. The default drop behavior is appropriate for most environments that do not require TCP Fast Open support.

Syslogs:

None

----------------------------------------------------------------

tcp-syn-ooo

Out-of-sequence SYN on established connection

The device received a TCP SYN packet on a connection that is already in the established state, but the sequence number in the SYN does not match the expected sequence number for that connection. This typically occurs when a retransmitted SYN packet from the original connection setup arrives late, after the three-way handshake has already completed and data transfer has begun. It can also indicate network path issues causing severe packet reordering, or potentially malicious activity attempting to inject packets into an existing connection. The device drops these packets as part of TCP normalization to maintain connection integrity and prevent sequence number attacks.

Recommendation:

This counter incrementing occasionally is normal behavior in networks with packet loss or reordering, especially during periods of congestion or path changes. The original connection remains unaffected. Investigate if you observe a high or sustained rate of these drops: check for network congestion, asymmetric routing, or link quality issues between clients and servers. Review packet captures to confirm whether these are legitimate retransmissions arriving out of order or potentially malicious traffic. If the rate is low and connections are functioning normally, no action is required.

Syslogs:

None

----------------------------------------------------------------

tcp-synack-data

TCP SYN-ACK with Data

This counter increments when the device receives a TCP SYN-ACK packet that contains a data payload during the three-way handshake. Standard TCP connection establishment does not include data in the SYN-ACK response from the server; only the SYN, SYN-ACK, and ACK flags are exchanged before data transmission begins. The presence of data in a SYN-ACK packet violates normal TCP behavior and may indicate an evasion attempt, protocol anomaly, or corrupted packet. However, TCP Fast Open (RFC 7413) is a legitimate protocol extension that allows servers to send data in SYN-ACK packets to reduce latency. By default, the device drops these packets as part of TCP normalization to enforce strict protocol compliance and prevent potential attacks. This behavior is controlled by the 'synack-data' setting in the TCP normalization policy applied to the traffic.

Recommendation:

First, determine whether the dropped traffic is legitimate or malicious. Use packet capture to examine the source and destination of the SYN-ACK packets. If the traffic involves applications or services that use TCP Fast Open (such as some web servers, CDNs, or optimized client-server applications), the drops are expected with the default policy. To allow TCP Fast Open traffic, configure a TCP map with 'synack-data allow' and apply it to the appropriate traffic class through a service policy. If the traffic is not using TCP Fast Open, investigate the server sending SYN-ACK packets with data—this may indicate misconfigured network equipment, corrupted packets due to hardware issues, or an active attack. In attack scenarios, maintain the default drop behavior. If drops persist from unknown or untrusted sources, verify network cabling and intermediate devices for corruption issues, and consider blocking the source if malicious activity is confirmed.

Syslogs:

None

----------------------------------------------------------------

tcp-synack-ooo

SYN-ACK received on established TCP connection

The firewall received a TCP SYN-ACK packet for a connection that has already completed the three-way handshake and is in the established state. This occurs when a delayed or retransmitted SYN-ACK from the server arrives after the connection has already been established with the final ACK. The firewall's TCP state machine validates that SYN-ACK packets only appear during connection setup; receiving one after the connection is established indicates either a network delay causing severe packet reordering, a retransmission issue, or potentially malicious activity attempting to disrupt the connection state. The packet is dropped because accepting it could corrupt the connection's sequence number tracking or allow TCP state confusion attacks. This drop is most commonly seen when network conditions cause the original SYN-ACK to be delayed significantly, and the server retransmits it, but by the time the retransmission arrives, the client has already sent the final ACK using the original SYN-ACK, completing the handshake.

Recommendation:

This drop is typically benign and indicates normal network behavior when SYN-ACK retransmissions arrive late. The connection itself should already be established and functioning. If you see sustained or high counts, investigate whether network latency or packet loss between the server and firewall is causing excessive retransmissions during connection setup. Check for asymmetric routing that might cause the firewall to see packets out of order. Verify that servers are not experiencing performance issues causing slow responses during the TCP handshake. If the drops correlate with application connectivity problems, capture packets on both sides of the firewall to determine if legitimate traffic is being affected. In most cases, no action is required as the established connection continues to function normally.

Syslogs:

None

----------------------------------------------------------------

tcp_xmit_partial

TCP partial retransmission detected

The device detected a TCP retransmission where the segment sequence number partially overlaps with previously transmitted data, but the overlap pattern indicates the retransmitted data may differ from the original. This counter increments only when the 'check-retransmission' feature is enabled in a TCP map policy applied to the connection. The feature validates retransmissions by computing a hash of TCP payload data and comparing it against stored hashes of previously seen segments. A partial overlap occurs when a retransmitted segment's sequence number falls within the range of earlier data but the segment boundaries or content don't align exactly—for example, a retransmit of bytes 100-150 when the device previously saw bytes 100-120 and 130-150 separately, or when the retransmitted data hash doesn't match the stored hash for that sequence range. The device drops the suspicious segment and sends a duplicate ACK to the sender to trigger a proper retransmission with the correct data.

Recommendation:

This drop is typically benign and indicates the TCP retransmission validation feature is working as designed to prevent retransmission-based attacks. The duplicate ACK sent by the device should cause the sender to retransmit the data correctly. However, if you see sustained or high rates of this counter: (1) Verify that 'check-retransmission' is intentionally enabled in your TCP map—this feature is not enabled by default and must be explicitly configured. (2) Check whether legitimate application traffic patterns involve unusual retransmission behavior that triggers false positives, such as applications that intentionally modify data in retransmits or use non-standard TCP implementations. (3) Capture packets on both sides of the device to determine whether the partial overlaps represent actual attack attempts or legitimate network conditions such as packet reordering combined with retransmissions. (4) If the feature is causing application failures, consider disabling 'check-retransmission' for the affected traffic by modifying the TCP map policy. Contact Cisco TAC if drops persist and correlate with application connectivity issues.

Syslogs:

None

----------------------------------------------------------------

tcpnorm-rexmit-bad

TCP retransmission with mismatched data

The connection was reset because a retransmitted TCP segment contained different payload data than the original transmission. This counter increments only when retransmission validation is enabled in a TCP map policy applied to the connection. The firewall maintains a hash of previously transmitted TCP segments and compares retransmitted data against these stored values. When a segment with the same sequence number arrives with different payload content, it indicates either a TCP retransmission-based evasion attack or a protocol anomaly. The firewall drops the mismatched segment and resets the connection to prevent potential security bypass. This protection defends against attacks where malicious actors send one payload to the firewall for inspection and a different payload in the retransmission to the end host, exploiting timing or inspection gaps.

Recommendation:

This drop typically indicates either a security attack or unusual network behavior. First, verify that retransmission checking is intentionally enabled in your TCP map configuration. If the feature is required for security, investigate the source of the traffic: legitimate applications should never send different data in retransmissions. Examine packet captures to determine whether the mismatched retransmissions are malicious or caused by a misbehaving application or middlebox. If legitimate traffic is being blocked, you may need to disable retransmission checking for specific traffic classes or review whether network devices between the client and firewall are modifying TCP payloads. For suspected attacks, correlate with other security events and consider blocking the source. If drops occur frequently on trusted traffic, the feature may not be appropriate for your environment.

Syslogs:

None

----------------------------------------------------------------

tcpnorm-win-variation

TCP window size decreased unexpectedly

This counter increments when the device detects that a host has advertised a smaller receive window than it previously announced, without having received enough data to justify the reduction. This behavior, known as window shrinking, violates recommended TCP practices and can indicate either a misbehaving endpoint or an evasion attempt. The device tracks the right edge of each endpoint's advertised receive window (the acknowledgment number plus the window size). When a new packet shows a right edge that is smaller than the previous value, the device flags this as a window variation. By default, the device allows such packets, but when configured to enforce strict window behavior using the tcp-map window-variation command, the device will reset the connection and increment this counter.

Recommendation:

Review the affected connections to determine whether the window shrinking is caused by legitimate but non-compliant endpoints or by malicious traffic. If the drops are affecting legitimate applications, disable window variation enforcement by configuring 'window-variation allow-connection' in the tcp-map applied to the affected traffic class. If you need to enforce strict TCP compliance for security reasons, keep the default 'window-variation drop-connection' setting and work with application owners to correct the endpoint behavior. Note that some older or embedded TCP stacks may exhibit this behavior under memory pressure. Check for patterns in the source or destination addresses to identify specific hosts that need policy exceptions.

Syslogs:

None

----------------------------------------------------------------

telnet-not-permitted

Telnet not permitted on least secure interface

The device blocked an attempt to establish a Telnet management session because the connection arrived on the least secure interface (the interface with the lowest security level in the security context) and was not protected by IPsec encryption. This is a security policy that prevents cleartext transmission of management credentials over untrusted networks. The counter increments when a TCP SYN packet destined to port 23 arrives on an interface that has the lowest security level in its context (typically the outside interface with security level 0) and the packet was not decrypted from an IPsec tunnel. Interfaces at maximum security level (100) are exempt from this restriction.

Recommendation:

This drop is by design and protects against credential exposure. To manage the device via the least secure interface, first establish an IPsec VPN tunnel to that interface, then initiate the Telnet session over the encrypted tunnel. Alternatively, use SSH instead of Telnet for encrypted management access, or connect via a more secure interface (higher security level). If Telnet access from the least secure interface is not required, no action is needed—this counter indicates the security policy is working correctly. Review the 'telnet' command configuration to ensure only trusted networks are permitted, and verify that IPsec tunnels are properly configured if remote management is required.

Syslogs:

402117

----------------------------------------------------------------

tfw-no-mgmt-ip-config

No management IP address configured for transparent firewall

This counter increments when the device is operating in transparent firewall mode and receives through-the-box traffic on an interface that has no management IP address configured. In transparent mode, the device operates at Layer 2 but requires a management IP address on the Bridge Virtual Interface (BVI) for each bridge group to perform security validation checks on transit traffic. Without this IP address, the device cannot validate source IP addresses against network and broadcast address rules, and must drop the packet as a security precaution. This affects both IPv4 and IPv6 traffic. The drop occurs during early packet processing before flow creation, and applies to all transit traffic through interfaces in bridge groups that lack IP configuration.

Recommendation:

Configure a management IP address on the BVI interface for each bridge group operating in transparent mode. Use the 'interface BVI<number>' command followed by 'ip address <address> <netmask>' to assign an IPv4 address, and 'ipv6 address <address>/<prefix>' for IPv6. The management IP does not need to be in the same subnet as the bridged traffic, but it must be configured for the device to perform security checks. If you are using failover, also configure the standby IP address. Verify the configuration with 'show interface BVI<number>' and 'show bridge-group'. After adding the management IP, traffic should flow normally and this counter should stop incrementing. If the counter persists after configuration, verify that the correct bridge group number is assigned to the interfaces and that the BVI interface is in an 'up' state.

Syslogs:

322004

----------------------------------------------------------------

ttl-exceeded

TTL Exceeded

The device received an IP packet with a Time-To-Live (IPv4) or Hop Limit (IPv6) value too low to be forwarded. When the 'set connection decrement-ttl' command is configured in a service policy, the device decrements TTL for matching traffic to make itself visible in traceroute operations; packets arriving with TTL of 1 are dropped because decrementing would result in TTL of 0. Without this command configured, only packets that already have TTL of 0 are dropped. For IPv4, when decrement-ttl is enabled and a packet is dropped, the device sends an ICMP Time Exceeded message back to the source. IPv6 packets destined to the device itself (identity interface) are allowed with hop limit of zero per RFC 8200. This counter increments for both routed and transparent mode traffic.

Recommendation:

If this counter is incrementing unexpectedly, verify whether 'set connection decrement-ttl' is configured in any service policy. If enabled, ensure that legitimate traffic has sufficient TTL to traverse the device—packets must arrive with TTL of at least 2. Be aware that routing protocols such as OSPF send hello packets with TTL of 1; applying decrement-ttl to these flows will cause them to be dropped and may disrupt adjacencies. If the drops are unintended, either remove the decrement-ttl configuration or adjust the service policy class-map to exclude the affected traffic. If you need traceroute visibility but must preserve low-TTL protocol traffic, use more specific traffic classification to apply decrement-ttl only to the desired flows. Note that no syslog message is generated for these drops; use packet captures or 'show asp drop' to confirm the behavior.

Syslogs:

None

----------------------------------------------------------------

tunnel-pending

IPsec tunnel SA not ready or being deleted

Packets were dropped because the IPsec tunnel Security Association is not yet established or is being torn down. This occurs in two scenarios: (1) Outbound traffic matching a crypto policy arrives before IKE negotiation completes the SA, or while the SA is being rekeyed or deleted. (2) Inbound decrypted traffic attempts to create a new flow through a tunnel that is in the process of being deleted. During normal tunnel establishment, the first few packets that trigger IKE negotiation will increment this counter until the SA comes up. During tunnel teardown or SA deletion, packets in flight may also hit this condition. The counter also increments when a tunnel SA has been deleted but existing flows have not yet been cleaned up.

Recommendation:

This is typically a transient condition during tunnel lifecycle events. Small increments during tunnel establishment or teardown are normal. If the counter increments continuously for an established tunnel, verify that IKE negotiation is completing successfully using 'show crypto ikev1 sa' or 'show crypto ikev2 sa', and check 'show crypto ipsec sa' to confirm the SA is in the UP state. Persistent increments may indicate IKE negotiation failures, mismatched crypto parameters between peers, or frequent tunnel flapping. Check for IKE or IPsec error messages in the logs. If the tunnel appears up but the counter continues to increment, the SA may be repeatedly failing and recovering—investigate peer reachability, authentication credentials, and crypto policy consistency.

Syslogs:

None

----------------------------------------------------------------

unable-to-add-flow

Flow hash table insertion failed

The device attempted to create a new connection but could not insert the flow entry into the internal hash table used to track active sessions. This occurs when the hash table's internal data structure cannot accept new entries, typically due to resource exhaustion in the hash table itself (all hash buckets full or experiencing severe collision) or transient lock contention during high connection rates. This is distinct from configured connection limits—the hash table has a fixed capacity based on platform memory and cannot grow beyond that size. When this counter increments, new connection attempts are dropped even though the device may not have reached any configured connection limit.

Recommendation:

Check current connection count with 'show conn count' and compare against platform maximums. Review 'show conn' output to identify connections that may have exceeded their idle timeouts but are still consuming hash table entries—stale connections prevent new ones from being created. If connection counts are reasonable but this counter is incrementing, the hash table may be experiencing internal fragmentation or collision issues. Reduce connection rate if possible, or clear stale connections with 'clear conn' for specific addresses. If the problem persists with normal connection counts well below platform limits, contact Cisco TAC as this may indicate hash table corruption or a platform resource issue that requires deeper analysis.

Syslogs:

None

----------------------------------------------------------------

unable-to-add-to-owner-table

VPN director failed to add IKE tunnel ownership entry

This counter increments when a cluster member acting as the VPN director cannot add an ownership entry for an incoming IKE (ISAKMP) negotiation. In ASA/FTD clustering with site-to-site or remote-access VPN, the VPN director role determines which cluster member should own each VPN tunnel based on a hash of the IKE endpoints. When the director receives the first packet of a new IKE negotiation, it must record the tunnel ownership in an internal hash table. This drop occurs if that hash table insertion fails, typically due to memory exhaustion or resource limits. The IKE negotiation cannot proceed, and the remote peer will retry.

Recommendation:

Check memory utilization on the cluster member with 'show memory' and 'show blocks'. If memory is exhausted, investigate what is consuming memory (NAT translations, connections, VPN sessions). Review cluster VPN load distribution with 'show cluster info vpn' to verify the VPN director is not overloaded. If the counter increments persistently under normal load, contact Cisco TAC with the output of 'show asp drop', 'show memory', 'show cluster info', and 'show vpn-sessiondb summary'.

Syslogs:

None.

----------------------------------------------------------------

unable-to-create-flow

Flow denied due to resource exhaustion

The firewall dropped a packet because it could not allocate resources to create a new connection. This occurs when one of three system limits is reached: (1) application cache memory is exhausted and cannot allocate the connection structure, (2) the system-wide connection handle pool is depleted (indicating the maximum concurrent connection limit has been reached), or (3) internal lock initialization fails due to memory pressure. The firewall attempts to reclaim resources by deleting preemptable connections before dropping new traffic. This counter typically increments during sustained high connection rates, memory exhaustion conditions, or when per-context connection limits are reached in multi-context deployments. When app-cache memory allocation fails, syslog message 302311 is generated showing the memory threshold percentage and whether threshold checking is enabled.

Recommendation:

Check system resource utilization with 'show resource usage' to identify which limit is being hit—look for connection count approaching the configured limit and check the 'Denied' column for resource denials. Use 'show memory' and 'show memory detail' to verify free memory is not critically low (below 5%). If app-cache memory is the issue, review 'show memory app-cache' for pool exhaustion. In multi-context deployments, verify per-context connection limits with 'show resource usage resource conns' in each context. If drops occur during traffic bursts but resources appear adequate, the system may be hitting transient allocation delays under high connection rates (see CSCwd60102). Consider increasing connection limits if headroom exists, reducing traffic load, or adjusting per-context resource allocations. If memory is consistently low, investigate memory leaks or reduce inspection features. Contact TAC if drops persist with adequate configured limits and available memory.

Syslogs:

302311

----------------------------------------------------------------

unable-to-create-vpn-fwd-cflow

Unable to create cluster stub flow for forwarded VPN traffic

This counter increments when a cluster member receives a VPN-decrypted packet forwarded from another cluster member but cannot create the required stub flow to process it. This occurs in cluster deployments with site-to-site VPN, particularly in centralized VPN mode, when the VPN session owner decrypts traffic and forwards it to another member for egress routing. The stub flow creation can fail due to memory exhaustion, flow table capacity limits, or inability to acquire internal locks during flow cleanup. Common triggers include high connection rates during cluster topology changes, member joins or departures, or sustained resource pressure on the receiving cluster member.

Recommendation:

Check cluster health and resource utilization on all members using 'show cluster info' and 'show resource usage'. Verify flow table capacity with 'show conn count' and compare against platform limits. If the counter increments during cluster membership changes, this may be transient and self-correcting once the cluster stabilizes. For persistent increments, consider distributing VPN sessions across more cluster members by configuring distributed VPN mode ('vpn-mode distributed' under cluster configuration) to reduce forwarding requirements. If memory or flow table exhaustion is indicated, review connection limits and consider scaling the cluster or reducing concurrent connection load. Contact Cisco TAC if drops persist after cluster stabilization, providing 'show asp drop' output, cluster topology details, and VPN configuration.

Syslogs:

None.

----------------------------------------------------------------

unable-to-find-owner

Packet dropped because cluster VPN director could not determine tunnel owner

This counter increments when a cluster member acting as the VPN director for a site-to-site IPsec tunnel cannot determine which cluster member should own the connection. The VPN director role is part of distributed VPN mode in ASA and FTD clusters, where site-to-site VPN tunnels are load-balanced across cluster members rather than centralized on the control node. When an ISAKMP (IKE) packet arrives, the director uses port-based hashing to assign ownership to a specific cluster member. This drop occurs in two scenarios: (1) the director is actively synchronizing its ownership table due to a cluster topology change (member joining or leaving), or (2) the director successfully added the tunnel entry but the subsequent owner lookup failed, indicating a transient state inconsistency in the director table. These drops are typically brief and self-correcting as the cluster stabilizes after membership changes.

Recommendation:

Check cluster health and stability using 'show cluster info' and verify all expected members are present and in a stable state. Review 'show vpn-sessiondb summary' to confirm VPN sessions are distributed across members as expected. If drops persist after cluster stabilization, check for syslog message 8300006 indicating repeated topology changes that abort VPN redistribution. Transient drops during cluster member joins or leaves are normal and expected; the VPN director temporarily rejects new tunnel establishment requests while synchronizing state. If drops occur continuously without cluster changes, collect 'show asp drop' output over time, 'show cluster vpn-sessiondb distribution', and contact Cisco TAC with a diagnostic bundle. In environments with frequent cluster topology changes, consider whether centralized VPN mode may be more appropriate for your deployment.

Syslogs:

8300006

----------------------------------------------------------------

unable-to-find-vpn-context

Unable to find VPN context for cluster-redirected encryption

This counter increments when a cluster member receives a packet redirected from another member for IPsec encryption, but cannot locate the VPN context (crypto map and tunnel configuration) needed to encrypt the packet. In a cluster, packets requiring encryption may be forwarded from the flow owner to a member that holds the IPsec tunnel. The receiving member must look up the encryption policy and associated tunnel parameters; if this lookup fails—because the crypto map is not configured, the tunnel has been deleted, or the Security Association is in transition—the packet is dropped. This typically occurs during crypto map configuration changes, IPsec SA deletion or rekey operations, or when cluster synchronization of VPN state is incomplete.

Recommendation:

Check that IPsec crypto maps and tunnel configurations are consistent across all cluster members. Review recent configuration changes to VPN policies. If drops occur during steady-state operation, examine 'show crypto ipsec sa' and 'show vpn-sessiondb' output to verify that tunnels are established and active on the expected members. Transient drops during SA rekey or tunnel re-establishment are typically self-correcting. Persistent drops may indicate a cluster synchronization issue or a defect in VPN context management (see CSCwc95290 for a known issue with SA deletion leaving stale context references). If drops persist after verifying configuration consistency, collect 'show tech-support' and 'show cluster info' output and contact Cisco TAC.

Syslogs:

None.

----------------------------------------------------------------

unable-to-replicate-packets

Broadcast or multicast packet dropped due to insufficient memory for context replication

This counter increments when the firewall cannot replicate a broadcast or multicast packet to all security contexts sharing an interface due to memory exhaustion. In multi-context mode, when an interface is shared across multiple contexts, broadcast and multicast traffic must be copied (looped back) to each context. Each copy requires packet metadata memory. When the packet block extension memory pool is depleted, the system cannot create the additional copies needed, and the original packet is dropped. This drop affects only the contexts that would have received the replicated copies; it does not indicate a problem with the original packet itself. The condition typically occurs under sustained high traffic loads in multi-context deployments with shared interfaces processing significant broadcast or multicast traffic (ARP, routing protocols, DHCP, etc.).

Recommendation:

Check overall system memory utilization with 'show memory' and 'show blocks'. If free memory is consistently low, investigate what is consuming memory—high connection counts, large ACLs, or other resource-intensive features. Consider reducing the number of contexts sharing the affected interface, or migrating to dedicated (non-shared) interfaces per context if the architecture permits. If broadcast or multicast traffic volume is high, evaluate whether all such traffic is necessary—for example, limit broadcast domains via VLANs or reduce unnecessary multicast group memberships. Monitor the counter over time; occasional increments during traffic spikes may be acceptable, but sustained growth indicates insufficient memory for the deployment's scale. If the issue persists despite adequate memory, contact Cisco TAC with 'show tech-support' output.

Syslogs:

None

----------------------------------------------------------------

unexpected-packet

Unexpected packet

This counter increments when a packet destined to the device itself cannot be processed because no service handler is registered to receive it. This occurs when the device receives a packet addressed to one of its own IP or MAC addresses, but the internal processing path finds no active service (such as management protocols, routing protocols, or other control-plane functions) configured or running to handle that specific traffic type. Common scenarios include: packets sent to the device on protocols or ports where no service is listening; inter-VRF routed traffic where the egress interface lacks a valid route and the next-hop resolves to an invalid address (such as 0.0.0.0); VPN tunnel traffic when certain IPsec inner routing features are enabled but routing fails; and cluster or high-availability control traffic during configuration transitions. The counter may also increment during normal operations such as cluster member joins, interface state changes, or failover events when transient mismatches occur between data-plane readiness and control-plane state.

Recommendation:

First, determine whether the device is experiencing an actual traffic processing issue or if the counter is incrementing during expected state transitions. Use packet capture and packet-tracer to identify the specific traffic triggering the drops—look for the destination IP/MAC, protocol, and ports. If drops occur during steady-state operations, verify that required services are enabled and listening on the correct interfaces. For inter-VRF routing scenarios, confirm that all VRFs have complete routing tables and that ECMP zones are properly configured. If the device uses route-based VPN tunnels, review the 'crypto ipsec inner-routing-lookup' configuration—disabling this feature may resolve drops in certain VPN topologies. For cluster or high-availability deployments, verify that control-link interfaces are up and that cluster or failover configuration is synchronized across all members. If drops occur only during configuration changes, interface state transitions, or cluster membership changes, they are typically transient and self-resolving. Persistent drops during normal traffic flow indicate a configuration gap—contact Cisco TAC with packet captures, packet-tracer output, and the full routing table from all relevant VRFs.

Syslogs:

None

----------------------------------------------------------------

unsupport-ipv6-hdr

Unsupported IPv6 Extension Header

The firewall dropped an IPv6 packet containing an extension header that is not supported or is explicitly blocked for security reasons. Supported extension headers include: Hop-by-Hop Options, Destination Options, Fragment, Authentication Header (AH), and Encapsulating Security Payload (ESP). The firewall explicitly blocks IPv6 Routing extension headers (all types) due to known security vulnerabilities, particularly Type 0 routing headers which can be exploited for amplification attacks. Mobility headers and any other unrecognized extension header types are also dropped. Note that while AH and ESP headers are supported for through-the-firewall traffic, packets with these headers destined to the firewall itself (management traffic) are not supported and will increment this counter.

Recommendation:

This drop is typically intentional and protects against known IPv6 security vulnerabilities. If you see this counter incrementing, first identify which extension header is being dropped by enabling packet capture or reviewing syslog messages (message ID 325005 may provide details). If the drops involve Routing extension headers, this is expected security behavior and should not be changed—these headers are deprecated due to security risks. If legitimate traffic is being dropped due to other extension header types, verify that the sending application or device is using standard IPv6 extension headers. For ESP or AH traffic destined to the firewall itself (such as management plane IPsec), note that only through-the-firewall IPsec is supported; management traffic with these headers will be dropped. If you observe large numbers of drops or drops from unexpected sources, investigate for potential reconnaissance or denial-of-service activity. Contact Cisco TAC if legitimate application traffic is being dropped and you have confirmed the extension headers in use are standard and necessary.

Syslogs:

325005

----------------------------------------------------------------

unsupported-ip-version

Unsupported IP Version

The security appliance received a packet with an invalid IP version number in the IP header. Valid IP packets must have version 4 (IPv4) or version 6 (IPv6) in the 4-bit version field at the start of the IP header. Any other value (0-3, 5, 7-15) causes the packet to be dropped during initial header validation. This drop occurs across all traffic paths including regular data plane traffic, cluster control link packets, high availability link traffic, and packets forwarded to or from service modules. Common causes include network transmission errors that corrupt packet headers, malfunctioning network equipment that generates malformed packets, or deliberate packet crafting in attack scenarios.

Recommendation:

Investigate the source of the malformed packets. Use packet capture on the affected interface to examine the actual IP version field values in dropped packets. Check for patterns: if drops are sporadic and low-volume, they may indicate transient network issues such as cable problems, duplex mismatches, or electromagnetic interference causing bit errors. If drops are consistent from specific sources, investigate those devices for hardware failures (faulty NICs, switch ports) or software bugs. If drops occur only on cluster control links or HA links, verify the health of those dedicated interfaces and cables. High volumes of these drops, especially from external sources, may indicate a denial-of-service attack or network scanning activity. In most cases, these drops are protective and prevent the appliance from processing invalid packets that could cause instability.

Syslogs:

None.

----------------------------------------------------------------

unsupported_8021q_vlan_tags

Unsupported 802.1Q VLAN tags

The device received a packet with more nested VLAN tags than the interface type supports. Inline sets and passive interfaces support up to two 802.1Q headers (Q-in-Q or double tagging), allowing one outer tag and one inner tag. Regular firewall interfaces support only a single 802.1Q header. When a packet arrives with additional layers of VLAN tags beyond these limits, the device cannot process it and drops the packet. This typically occurs when traffic is incorrectly forwarded from network equipment that adds multiple levels of VLAN encapsulation, or when Q-in-Q traffic is sent to a firewall interface that does not support it. The device recognizes standard 802.1Q ethertypes (0x8100), 802.1ad provider bridging (0x88A8), and non-standard Q-in-Q ethertypes (0x9100, 0x9200).

Recommendation:

Verify the interface type and VLAN tagging requirements. If using inline sets or passive interfaces, ensure traffic does not exceed two levels of 802.1Q tags. If using regular firewall interfaces, traffic must have only a single VLAN tag. Check upstream switches and routers to confirm they are not adding excessive VLAN encapsulation. If Q-in-Q traffic is required, configure inline sets or passive interfaces rather than firewall interfaces. Review the network topology to ensure VLAN tag stacking matches the device's capabilities for the configured interface type.

Syslogs:

None

----------------------------------------------------------------

uztna-policy-data-not-found

Hybrid Zero Trust policy data not found

The device dropped a packet because it could not find the required policy metadata for a Hybrid Zero Trust Network Access (UZTNA) connection. When a UZTNA client initiates a connection through the ZProxy component, the ZProxy sends policy metadata (including user identity, device posture, and inspection policy assignments) to the FTD device via a metadata channel. This metadata must be present before the FTD device can create the corresponding security flow. This counter increments when the FTD attempts to establish a flow for UZTNA traffic but cannot locate the metadata object in its metadata table. Common causes include: the metadata message from ZProxy has not yet arrived, the metadata has expired due to timing issues, or communication between ZProxy and the FTD metadata server has failed. This drop only occurs on devices configured for Hybrid ZTNA with active ZProxy integration.

Recommendation:

Verify that the Hybrid ZTNA configuration is correct and that the ZProxy component can communicate with the FTD device on the metadata channel (UDP port for metadata exchange). Check for network connectivity issues between ZProxy and FTD. Use 'show zero-trust' commands to verify UZTNA configuration status and active sessions. Enable 'debug zero-trust' to trace metadata message exchange and identify whether metadata requests are being received and processed. If drops persist, verify that clocks are synchronized between ZProxy and FTD, as metadata objects have expiration timers. Check for high connection rates that might cause metadata messages to arrive after flow creation attempts. If the issue continues after verifying configuration and connectivity, collect troubleshooting outputs and contact Cisco TAC for assistance with Hybrid ZTNA deployment.

Syslogs:

None.

----------------------------------------------------------------

uztna-src-translation-failure

Universal Zero Trust source NAT pool exhaustion

The firewall dropped a packet because the source NAT pool configured for Universal Zero Trust (Hybrid ZTNA) traffic has no available IP addresses or ports. This occurs when client devices connecting to Zero Trust applications require source address translation, but all addresses or port allocations in the configured pool are already in use by existing connections. The pool is defined using the 'mapped-source-v4' command under 'zero-trust-hybrid' configuration mode, which specifies a network object or object group containing the IP addresses available for translating client source addresses before forwarding traffic to protected applications.

Recommendation:

Expand the source NAT pool by adding more IP addresses to the network object or object group referenced in the 'mapped-source-v4' configuration. Review active NAT translations with 'show xlate' to identify whether connections are being held longer than necessary due to application timeouts or stale sessions. If the pool is appropriately sized but exhaustion persists, investigate whether connection rates exceed design capacity or whether NAT timeouts need adjustment. In clustered deployments, verify that port block allocation is balanced across cluster members. This counter is specific to Zero Trust traffic and does not affect other NAT policies.

Syslogs:

None.

----------------------------------------------------------------

vaccess-channel

Virtual access interface ingress drop

The security appliance received a packet on a virtual access interface and dropped it. Virtual access interfaces are dynamically created for VTI (Virtual Tunnel Interface) and dynamic VTI configurations. These interfaces are designed for outbound (egress) traffic only—packets should be routed through them for IPsec encryption, not received on them. This counter increments when packets arrive on the interface itself, which typically occurs with protocol control traffic such as ARP requests, IPv6 neighbor solicitation/advertisement messages, ICMP packets, or multicast traffic that the VTI architecture does not support on the interface layer.

Recommendation:

This is expected behavior and typically benign. Virtual access interfaces do not process incoming packets at the interface layer. If this counter increments steadily, verify that routing is correctly configured—traffic should be routed through the VTI tunnel for encryption, not directly to the virtual access interface as a destination. Common scenarios include ARP or neighbor discovery protocols attempting to resolve addresses on the VTI interface, which is not supported. No action is required unless you observe functional issues with VPN traffic flow. If VPN tunnels are not establishing or traffic is not passing through the tunnel, review the IPsec configuration, routing table, and crypto map or tunnel-group associations rather than focusing on this counter.

Syslogs:

None.

----------------------------------------------------------------

vPath-license-failure

Traffic dropped due to virtual security service license failure

This counter increments when traffic is dropped because the virtual security appliance cannot validate its license entitlement. This applies exclusively to the ASA 1000V virtual security appliance running on Nexus 1000V distributed virtual switch infrastructure. The ASA 1000V uses a license model where virtual machine instances consume licenses from a pool managed by the Nexus 1000V Virtual Supervisor Module. When the appliance cannot verify sufficient licensed capacity—either because all available licenses are consumed by other instances, the license server is unreachable, or the license has expired—new connections are dropped and existing flows may be terminated. The drop typically affects all traffic attempting to traverse the virtual appliance until licensing is restored.

Recommendation:

Verify license availability on the Nexus 1000V Virtual Supervisor Module using the Nexus 1000V management interface. Check that sufficient ASA 1000V licenses are installed to cover all active virtual appliance instances in the environment. On the ASA 1000V itself, use 'show license' to view available license entitlements and 'show license usage' to see current consumption. If licenses are exhausted, either add additional licenses to the pool or reduce the number of active ASA 1000V instances. If the license server is unreachable, verify network connectivity between the ASA 1000V and the Nexus 1000V management infrastructure. Note that the ASA 1000V platform has reached end-of-life; consider migrating to current virtual appliance platforms (ASAv or FTDv) which use modern licensing mechanisms.

Syslogs:

4450002

----------------------------------------------------------------

vpn-cflow-fail-due-to-full-flow

Packet dropped due to conflicting flow ownership in cluster VPN forwarding

This counter increments when a cluster member receives a decrypted VPN packet forwarded from another unit, but cannot create the required stub flow because a full flow already exists for the same connection. This represents a flow ownership conflict where two cluster members believe they own the same connection. The condition occurs exclusively in clustered deployments running site-to-site VPN in distributed mode, where VPN sessions are load-balanced across cluster members. The conflict typically arises during topology changes (member join/leave events, director reassignment) or with UDP-based VPN traffic where delayed synchronization between cluster members can cause temporary ownership ambiguity. When the receiving unit detects the conflict, it drops the forwarded packet to prevent duplicate flow processing.

Recommendation:

Occasional increments during cluster membership changes are expected and typically self-correct as the cluster converges on consistent flow ownership. Persistent or high-rate increments indicate a cluster synchronization issue. Check for: (1) frequent cluster membership changes or unstable cluster control link connectivity, (2) asymmetric routing causing packets for the same flow to arrive at different cluster members, (3) version mismatches between cluster members. For UDP-based VPN protocols (IKEv2, IPsec NAT-T), brief ownership conflicts during bulk synchronization are normal. If drops persist after the cluster stabilizes, collect troubleshooting bundles from all cluster members and contact Cisco TAC. Related counters to monitor: cluster-ccl-backup (indicates forwarding to backup owner), vpn-reclassify-fail (VPN context lookup failures).

Syslogs:

785001 (flow ownership moved between cluster units)

----------------------------------------------------------------

vpn-context-expired

Expired VPN context

The security appliance received an IPsec packet that requires decryption, but the internal tunnel context needed to process the packet is no longer valid. This occurs when the packet arrives after the associated IPsec Security Association (SA) has been deleted or during SA rekey operations when the context lookup fails. Common scenarios include: IPsec SA rekey operations where timing issues cause the old SA's context to be removed before the new SA is fully established; tunnel teardown when packets arrive after the SA has been deleted; or on high-availability standby units during flow synchronization when the VPN context has not yet been replicated. The counter may increment during normal IPsec tunnel operations, particularly during frequent rekey events or failover activity.

Recommendation:

Brief, transient increments during IPsec SA rekey operations or tunnel teardown are typically normal and do not indicate a problem. However, sustained or rapidly increasing counters during stable tunnel operation suggest an issue. Check for: (1) Frequent IPsec SA rekeys - review 'show crypto ipsec sa' and IKE/IPsec logs to determine if rekey intervals are unusually short; (2) High-availability synchronization issues - on standby units, verify that flow replication is functioning correctly with 'show failover' and check for related failover errors; (3) Memory pressure - use 'show memory' and 'show blocks' to check for resource exhaustion. If the counter increments persistently during normal traffic without rekey activity, or if IPsec tunnel traffic is being dropped, collect 'show asp table vpn-context detail', 'show crypto ipsec sa detail', packet captures with 'capture asp', and contact Cisco TAC. Known software defects in versions prior to 9.16.4.14, 9.18.3, and 7.0.6 could cause this issue during rekey operations.

Syslogs:

None

----------------------------------------------------------------

vpn-handle-error

VPN Handle Error

This counter increments when the device attempts to create a data plane context for an IPsec Security Association (SA) but discovers that a context already exists for that SA. This occurs during flow setup for IPsec traffic when the control plane requests creation of a new encryption or decryption context, but the data plane still has a stale context from a previous SA that was not properly cleaned up. Common triggers include IPsec SA rekey operations where the old SA's context was not fully deleted before the new SA attempted to create its context, SA deletion failures that left orphaned contexts, or timing issues during failover or cluster operations where context state becomes inconsistent between the control and data planes.

Recommendation:

This counter indicates an internal state synchronization issue between the IPsec control plane and the data plane VPN context management. Check for IPsec SA rekey activity or tunnel flapping around the time the counter incremented. Review IPsec tunnel status and look for SAs stuck in transitional states. If the counter is incrementing steadily during normal IPsec operations (especially during rekey events), this may indicate a software defect in VPN context lifecycle management. Collect the output of 'show asp table vpn-context', 'show crypto ipsec sa', 'show counters | include IPSEC', and 'show asp drop' at the time of the issue. Contact Cisco TAC if the counter increments frequently, as this typically requires a software fix to correct the context cleanup logic during SA transitions.

Syslogs:

316002

----------------------------------------------------------------

vpn-handle-mismatch

VPN Handle Mismatch

The appliance dropped an IPsec NAT-Traversal (NAT-T) packet because of an internal flow state inconsistency. During NAT-T packet processing, each packet carries a reference to its associated connection flow. This counter increments when that reference points to a different flow than the one actually handling the packet. This mismatch typically occurs with L2TP over IPsec traffic using NAT-T, particularly in large-scale deployments or when processing fragmented packets. The drop is a protective measure to prevent processing packets with incorrect flow state, which could lead to traffic corruption or system instability.

Recommendation:

This counter should remain at zero during normal operation. If you see increments, first verify you are running a current software version, as a defect affecting L2TP fragment handling with NAT-T was resolved in ASA 8.2(1.15) and all later releases. If the counter increments on current code, capture the output of 'show tech-support' and 'show asp drop' at the time drops occur, and contact Cisco TAC for analysis. The drops indicate an internal state inconsistency that requires engineering investigation. If you are using L2TP over IPsec with NAT-T and experiencing connectivity issues, this counter may indicate you are hitting the known fragmentation issue - upgrading to a fixed release should resolve it.

Syslogs:

None.

----------------------------------------------------------------

vpn-lock-error

IPsec VPN internal locking failure

This counter increments when the system cannot acquire internal locks needed to process IPsec tunnel traffic. The lock failure occurs when associating decrypted packets with their VPN tunnel context, creating new flows for tunnel traffic, or applying crypto ACLs to decrypted packets. This typically happens under high traffic load when many flows are simultaneously being created or torn down through the same IPsec tunnel, causing multiple processor cores to compete for access to the same VPN data structures. The condition is most common on multicore platforms processing high volumes of TCP connections through site-to-site VPN tunnels.

Recommendation:

This counter indicates internal resource contention rather than a configuration issue. If the counter is incrementing: (1) Check if you are running software earlier than 9.20—versions prior to 9.20 used less efficient locking mechanisms that were more prone to contention under load (see CSCwf50361). Upgrade to 9.20 or later if possible. (2) Monitor overall VPN tunnel traffic volume and connection rates with 'show crypto ipsec sa' and 'show conn'. If you are approaching platform connection limits or processing very high connection rates (thousands of new flows per second), the lock contention may be unavoidable on your current hardware. (3) If the counter increments occasionally during traffic bursts but traffic is passing normally, this is typically benign—affected packets will be retransmitted by TCP or the application. (4) If the counter increments continuously and you observe sustained packet loss through VPN tunnels, contact Cisco TAC with the output of 'show asp drop', 'show crypto ipsec sa detail', 'show conn count', and 'show cpu usage' to determine if you need a platform upgrade or if there is an underlying software issue.

Syslogs:

None

----------------------------------------------------------------

vpn-overlap-conflict

VPN Network Overlap Conflict

This counter increments when a decrypted IPsec packet's inner source and destination addresses match a different tunnel configuration than the one that decrypted it. After an encrypted packet is decrypted based on its outer headers and Security Parameter Index (SPI), the system examines the inner packet headers and compares them against all configured tunnels. If the inner addresses match the encryption domain (interesting traffic selectors) of a different tunnel than the one that performed the decryption, the packet is dropped to prevent routing ambiguity and potential security policy bypass. This typically occurs when multiple site-to-site VPN tunnels are configured with overlapping or identical local and remote network definitions, causing the same traffic to legitimately match multiple tunnel policies. The drop can also occur during tunnel reconvergence events when Equal-Cost Multi-Path (ECMP) configurations with multiple Virtual Tunnel Interfaces (VTI) are in use, or when duplicate IPsec Security Associations are inadvertently created for the same traffic selectors during IKEv2 rekey operations.

Recommendation:

Review your site-to-site VPN configuration for overlapping encryption domains. Check that each crypto map entry or VTI tunnel has unique and non-overlapping local and remote network definitions in their associated access lists or route-based configurations. If you intentionally have overlapping address spaces (for example, in ECMP VTI designs where multiple tunnels provide redundant paths to the same networks), verify that all tunnels are in the same security zone and properly configured for load balancing. For IKEv2 tunnels, if drops occur during tunnel re-establishment, check for duplicate child Security Associations using 'show crypto ipsec sa' and clear stale associations if necessary. Reorder crypto map entries so that more specific (longer prefix) matches appear before less specific ones. If the overlap is unintentional, modify the encryption domains to be mutually exclusive. For ECMP VTI scenarios experiencing transient drops during failover, these may be expected during convergence and should cease once routing stabilizes. Contact Cisco TAC if drops persist after correcting overlaps or if they occur without any apparent configuration overlap.

Syslogs:

None

----------------------------------------------------------------

vpn-reclassify-failed

VPN Reclassify Failed

This counter increments when an existing connection is dropped because it no longer matches current security policies after a VPN tunnel state change. This occurs when the 'sysopt connection reclassify-vpn' command is enabled (the default) and a VPN tunnel is established, torn down, or reconfigured. The system re-evaluates existing flows against the new VPN encryption policies; flows that now require encryption but were established as cleartext (or vice versa) are terminated and must be re-established. In cluster deployments running centralized VPN mode, this counter also increments on data units when a flow would require encryption, since data units cannot handle stateful VPN connections in that mode. Additionally, this drop can occur when ECMP path changes cause a tunnel flow to switch interfaces and the flow fails policy validation on the new path.

Recommendation:

This is typically expected behavior during VPN tunnel establishment or configuration changes, as the system ensures all traffic follows current encryption policies. If you see sustained or unexpected increments, verify: (1) Check for frequent tunnel flapping or SA renegotiation that would trigger repeated reclassification. (2) In cluster environments with centralized VPN, confirm that only the master unit is handling VPN traffic; data units will drop flows requiring encryption. (3) Review recent VPN configuration changes or crypto map modifications that might have altered which traffic should be encrypted. (4) If the drops affect legitimate cleartext traffic (non-VPN), this may indicate a software defect (see CSCwe07722); consider disabling automatic reclassification with 'no sysopt connection reclassify-vpn' as a workaround, though this prevents automatic flow cleanup when VPN policies change. After applying this workaround, existing connections may need to be cleared manually. Contact Cisco TAC if drops persist without corresponding VPN state changes or if they impact production traffic unexpectedly.

Syslogs:

Syslog 302014 (TCP connection teardown) or 302013 (UDP connection teardown) may accompany this drop, showing the specific connection being torn down due to policy mismatch.

----------------------------------------------------------------

vtemplate-channel

Packet sent to virtual template interface

This counter increments when a packet is sent to a virtual template interface. Virtual template interfaces are configuration templates used in dynamic Virtual Tunnel Interface (dVTI) deployments for IPsec VPN. They define parameters such as tunnel source, IPsec profile, and zone membership that are applied to dynamically created virtual access interfaces when VPN tunnels are established. Virtual template interfaces themselves do not carry traffic and are not intended to receive packets. Traffic should flow through the virtual access interfaces that are instantiated from the template. This drop typically occurs for protocol packets such as ICMP echo requests or multicast traffic that are mistakenly addressed to the template interface itself rather than to an active virtual access interface.

Recommendation:

This is expected behavior and does not indicate a problem. Virtual template interfaces serve only as configuration templates and should not receive traffic. Verify that your routing and VPN configuration directs traffic to the dynamically created virtual access interfaces (show interface virtual-access) rather than to the virtual template interface. If you see sustained or high counts, check whether ICMP or multicast traffic is being incorrectly addressed to the template interface IP or zone. For dVTI troubleshooting, use 'show crypto ipsec sa' and 'show interface virtual-access' to verify that virtual access interfaces are being created properly and that traffic is flowing through them.

Syslogs:

None

----------------------------------------------------------------

vti-channel

VTI channel drop

This counter increments when a packet is directed to be received on a Virtual Tunnel Interface (VTI), which is not supported. VTI interfaces are transmit-only logical interfaces used for route-based IPsec VPNs. Traffic encrypted through a VTI is sent out the tunnel, and decrypted traffic arrives via the IPsec subsystem and is routed to the appropriate destination—it does not arrive 'on' the VTI interface itself. This drop typically occurs when certain control-plane protocols (such as ICMP, multicast routing protocols like OSPF or PIM, or ARP) attempt to use the VTI as a receive interface, which violates the VTI architecture. In most cases, this is expected behavior and indicates that the system is correctly rejecting unsupported receive operations on the VTI.

Recommendation:

This drop is usually benign and expected. VTI interfaces do not support inbound packet reception—only transmission. If you see this counter incrementing, verify that: (1) Multicast routing protocols over VTI tunnels are properly configured with the correct source interfaces and PIM neighbors are established on the physical or tunnel source interfaces, not the VTI itself. (2) ICMP traffic destined to the VTI interface IP is not expected to be processed locally—ICMP to the tunnel endpoint should be addressed to the tunnel source interface. (3) ARP is not configured or expected on VTI interfaces, as they are point-to-point tunnels. If you are experiencing connectivity issues over VTI tunnels and see this counter increasing, check that routing is correctly directing traffic through the tunnel (use 'show route' and 'show crypto ipsec sa') rather than attempting to receive on the VTI interface. For multicast over VTI, ensure that multicast forwarding is enabled and that the VTI is included in the PIM configuration. If drops persist and affect traffic, collect 'show asp drop', 'show interface tunnel', 'show crypto ipsec sa', and 'show pim interface' (if using multicast) and contact Cisco TAC.

Syslogs:

None

----------------------------------------------------------------

vxlan-ccl-inner-dip-not-found

VXLAN cluster peer lookup failure

This counter increments when the device cannot identify the destination cluster member for a packet that needs to be forwarded over the VXLAN-based Cluster Control Link (CCL). This occurs when the destination MAC address in the packet does not match any known cluster member's MAC address in the membership table. The device needs this mapping to determine the correct VXLAN tunnel endpoint (remote VTEP IP address) for encapsulation, but the lookup fails. This typically happens during cluster forwarding operations when a non-owner unit attempts to forward traffic to the flow owner, during cluster state synchronization messages, or when processing unicast ARP requests in a clustered environment. The drop indicates that the destination cluster member may have left the cluster, is in a disabled state, or the membership table has not yet been updated to reflect current cluster topology.

Recommendation:

This counter usually indicates a transient cluster membership inconsistency. Check cluster status with 'show cluster info' to verify all expected members are present and in the correct state. If members are frequently joining and leaving, investigate CCL interface stability and network connectivity between cluster members. For VXLAN-based CCL (common in ASA Virtual deployments), verify that the NVE peer-group configuration includes all cluster member VTEP IP addresses and that VXLAN connectivity is stable. If the counter increments during normal operation with a stable cluster, check for timing issues where packets are being forwarded to a member that has just left the cluster. Review cluster health check logs and CCL interface statistics. Persistent increments may indicate configuration mismatches in the VXLAN peer group or MAC address pool settings. If the issue persists with a stable cluster topology, contact Cisco TAC for further analysis.

Syslogs:

None directly associated. Related cluster membership syslogs: 747xxx series (cluster status changes).

----------------------------------------------------------------

vxlan-encap-error

VXLAN encapsulation failure

This counter increments when the device cannot add VXLAN tunnel headers to a packet destined for transmission through a Network Virtualization Endpoint (NVE) interface. The encapsulation process wraps the original Layer 2 frame with outer Ethernet, IP, UDP, and VXLAN headers before sending it to a remote VTEP (VXLAN Tunnel Endpoint). Encapsulation can fail for two primary reasons: (1) the resulting encapsulated packet would exceed the maximum transmission unit (MTU) configured on the VTEP source interface or the system-wide maximum frame size, or (2) an internal buffer management error occurs while constructing the outer headers, typically indicating insufficient headroom in the packet buffer. VXLAN adds 50 bytes of overhead (14-byte Ethernet + 20-byte IP + 8-byte UDP + 8-byte VXLAN header), so the VTEP source interface MTU must accommodate both the original frame and this additional encapsulation. This drop occurs on the egress path when traffic is being sent from a VNI (VXLAN Network Identifier) interface to a remote peer.

Recommendation:

First, verify the MTU configuration on the VTEP source interface using 'show interface' and ensure it is at least 50 bytes larger than the largest frame expected on the VNI interfaces (typically 1550 bytes or higher for standard 1500-byte payloads). If the MTU is too small, increase it using the 'mtu' command on the VTEP source interface. Note that some platforms and interface types have MTU limitations—consult platform documentation for maximum supported values. If MTU settings appear correct, check for buffer allocation issues by reviewing system memory and block statistics with 'show blocks' and 'show memory'. Persistent drops with adequate MTU may indicate a software defect; collect 'show asp drop' output, interface configurations, and a packet capture on the VNI interface showing the dropped traffic, then contact Cisco TAC. For IPv6 VXLAN deployments, ensure the VTEP source interface MTU is at least 1280 bytes (the minimum IPv6 MTU) plus the 50-byte VXLAN overhead.

Syslogs:

None

----------------------------------------------------------------

vxlan-invalid-header

VXLAN packet with malformed header

The security appliance received a UDP packet on the configured VXLAN destination port (default 4789) but could not parse the VXLAN header. This occurs when the VXLAN header fails RFC 7348 validation: either the flags field does not match the expected value (bit 3 must be set to indicate a valid VNI, all other bits must be zero), or the reserved fields contain non-zero values. The packet is dropped because it cannot be decapsulated to extract the inner frame and VXLAN Network Identifier (VNI). This counter increments on VTEP interfaces when receiving VXLAN traffic from remote tunnel endpoints.

Recommendation:

This typically indicates a misconfigured or non-compliant VXLAN implementation on the remote tunnel endpoint. Verify that the peer VTEP is sending standards-compliant VXLAN packets. Use packet capture on the receiving interface to examine the VXLAN header structure. Check that the remote endpoint is not using proprietary VXLAN extensions or incorrect flag settings. If the remote device is a third-party VXLAN gateway, confirm it follows RFC 7348. If drops persist from a known-good peer, verify that no intermediate device is corrupting the VXLAN headers. This drop is expected and benign when the appliance receives non-VXLAN UDP traffic on port 4789 from sources that are not configured VXLAN peers.

Syslogs:

778004

----------------------------------------------------------------

vxlan-invalid-header-thru-traffic

Invalid VXLAN Header Format in Transit Traffic

The security appliance received a UDP packet on the configured VXLAN port (default 4789) but the VXLAN header failed validation. The appliance validates that the VXLAN header conforms to RFC 7348 requirements: the flags field must be set to 0x08 (indicating the VNI field is valid), and all reserved fields must be zero. This counter increments when transit VXLAN traffic has malformed headers, such as incorrect flag values, non-zero reserved bits, or other header format violations. This typically indicates misconfigured VXLAN endpoints, non-compliant VXLAN implementations, or corrupted packets.

Recommendation:

Verify that all VXLAN tunnel endpoints in your network are RFC 7348 compliant and properly configured. Check the source device generating the malformed VXLAN packets using the syslog message details (source/destination IP and port). If the source is a third-party device or virtual switch, confirm it is using standard VXLAN encapsulation with the I-flag set correctly. Capture and decode the dropped packets to identify the specific header field violations. If drops are persistent and affecting legitimate traffic, contact Cisco TAC with packet captures showing the malformed VXLAN headers.

Syslogs:

778004

----------------------------------------------------------------

vxlan-invalid-nve-peer

VXLAN packet from unconfigured peer

The device received a VXLAN packet from a source IP address that does not match any configured static peer. This occurs when the VTEP interface uses static peer configuration (via the 'peer ip' or 'peer-group' commands) instead of multicast-based peer discovery. When static peers are configured, the device validates the source IP of incoming VXLAN packets and drops any traffic from peers that are not explicitly listed in the configuration. This is a security feature that prevents unauthorized VTEPs from injecting traffic into the VXLAN overlay.

Recommendation:

Verify the VXLAN configuration on both the local and remote VTEPs. Check 'show run nve' to confirm which static peers are configured. If the source IP in the syslog message (778007) should be allowed, add it to the static peer configuration using 'peer ip <address>' under the NVE interface, or add it to the network object group referenced by the 'peer-group' command. If the source is not a legitimate VTEP, this drop is expected security behavior and no action is needed. If you intended to use multicast-based peer discovery instead of static peers, remove the static peer configuration and configure a multicast group on the VNI interface using the 'mcast-group' command. Note that static peer and multicast configurations are mutually exclusive.

Syslogs:

778007

----------------------------------------------------------------

vxlan-invalid-udp-checksum

VXLAN packet with invalid UDP checksum

The security appliance received a VXLAN-encapsulated packet on a VTEP interface where the outer UDP header contained a non-zero checksum value that failed validation. According to the VXLAN specification, the UDP checksum field is optional and may be set to zero to indicate no checksum. However, when a VXLAN sender includes a non-zero checksum, the receiving VTEP must validate it. This counter increments when that validation fails, indicating either packet corruption in transit or a misconfigured VXLAN sender that is computing checksums incorrectly. The packet is dropped and cannot be decapsulated.

Recommendation:

Check syslog message 778006 to identify the source VTEP IP address and port sending packets with invalid checksums. Investigate the sending VTEP device for potential hardware issues (NIC offload problems, memory errors) or software bugs that could cause checksum corruption. If the remote VTEP is a third-party device or virtual appliance, verify it is running current software and that UDP checksum offload is functioning correctly. In environments where VXLAN traffic traverses intermediate devices (load balancers, NAT gateways), confirm those devices are not corrupting the UDP checksum. If the issue persists and affects production traffic, consider engaging the vendor of the sending VTEP. Note that many VXLAN implementations set the UDP checksum to zero to avoid this class of problem; if feasible, configure the remote VTEP to transmit with zero checksums.

Syslogs:

778006

----------------------------------------------------------------

vxlan-invalid-vni-mcast-ip

Missing Multicast Group on VXLAN VNI Interface

This counter increments when the device attempts to send broadcast, multicast, or unknown unicast traffic over a VXLAN tunnel but cannot determine the destination because the VNI interface lacks a configured multicast group IP address. VXLAN uses multicast-based replication for broadcast, unknown unicast, and multicast (BUM) traffic when static peer configuration is not present. The drop occurs during encapsulation when the system needs to replicate traffic to multiple remote VTEPs but finds no multicast group configured on the egress VNI interface. This typically happens when: (1) the VNI interface has no 'mcast-group' command configured, (2) the VTEP source interface has no 'default-mcast-group' configured to provide a fallback, and (3) no static peer is configured via the 'peer ip' command. The counter will increment for broadcast frames (destination MAC ff:ff:ff:ff:ff:ff), multicast MAC addresses, and non-IP/non-ARP packets that require multicast replication.

Recommendation:

Configure a multicast group on the affected VNI interface using the 'mcast-group <multicast-ip>' command in VNI interface configuration mode, or configure a default multicast group on the VTEP source interface using 'default-mcast-group <multicast-ip>' in nve configuration mode. Alternatively, if multicast is not available in your environment (such as in multiple context mode), configure static VXLAN peers using the 'peer ip <address>' command in nve configuration mode. Verify the configuration with 'show nve <id>' and 'show interface vni <id>'. If the multicast group was configured but the counter still increments after a reload, this may indicate a known issue where the multicast group configuration does not take effect at boot time—in this case, remove and re-apply the multicast group configuration. Note that broadcast and multicast traffic cannot be forwarded over VXLAN without either multicast group configuration or static peer configuration.

Syslogs:

None.

----------------------------------------------------------------

vxlan-missing-peer-vtep-ip

Peer VTEP IP Not Found

This counter increments when the device cannot determine which remote VXLAN Tunnel Endpoint to use for encapsulating outbound traffic on a VNI interface. The device needs to map the inner packet's destination (either the destination IP address in routed mode, or the destination MAC address in transparent mode) to a remote VTEP IP address before it can build the outer VXLAN header. This mapping is learned dynamically through data-plane traffic or configured statically. The drop occurs when no mapping exists for the destination, meaning the device does not know which remote VTEP hosts the target endpoint. This typically happens during initial traffic flows before the device has learned the remote endpoint location, after a topology change, or when routing or adjacency information is incomplete on the VNI interface.

Recommendation:

Check whether the remote endpoint mapping exists using the appropriate command for your traffic type: 'show arp vtep-mapping' for IPv4 routed traffic, 'show ipv6 neighbor vtep-mapping' for IPv6 routed traffic, or 'show mac-address-table vtep-mapping' for transparent mode bridged traffic. If the mapping is missing, verify that the remote VTEP has sent traffic for the destination endpoint so the local device can learn it, or configure a static peer if using static VXLAN configuration. In routed mode, also verify that the VNI interface has a valid route to the inner destination IP address and that adjacency resolution is working. If drops persist after the remote endpoint should have been learned, check for routing issues on the VNI interface, verify the NVE and VTEP configuration is correct, and confirm that the remote VTEP is reachable and operational. Occasional drops during initial connection establishment or after topology changes are normal and expected.

Syslogs:

None.

----------------------------------------------------------------

wccp-redirect-no-route

WCCP Redirect Failed - No Route to Cache Engine

This counter increments when the security appliance attempts to redirect traffic to a cache engine via WCCP (Web Cache Communication Protocol) but cannot find a valid route or adjacency to reach the cache engine's IP address. When WCCP redirection is configured and traffic matches a service group, the appliance encapsulates the packet and performs a route lookup to determine how to reach the selected cache engine. If the route lookup returns no results, or if the adjacency lookup fails (meaning the next-hop MAC address cannot be resolved), the packet is dropped and this counter increments. This can occur in both routed and transparent firewall modes. In routed mode, the issue is typically a missing route in the routing table. In transparent mode, the appliance must find the cache engine in the Layer 2 adjacency table for the appropriate interface. VRF configurations can also cause this drop if the cache engine is not reachable within the correct VRF routing context.

Recommendation:

Verify that a route exists to the cache engine IP address using 'show route' (in routed mode) or verify Layer 2 adjacency using 'show arp' (in transparent mode). Check that the cache engine is reachable from the security appliance with ping or traceroute. If using VRFs, ensure the cache engine is reachable within the correct VRF context and that at least one interface is configured in the global VRF to provide a valid router identifier for WCCP communication. In transparent mode, verify that management interface convergence is not causing the appliance to incorrectly use the management routing table instead of the data routing table. Review WCCP service group configuration with 'show wccp' to confirm cache engines are properly registered and marked as usable. If the cache engine is down or unreachable, this drop is expected behavior until connectivity is restored. Contact Cisco TAC if routes exist but drops persist, as this may indicate a software defect related to VRF or transparent mode routing.

Syslogs:

None

----------------------------------------------------------------

wccp-return-no-route

No route to client for WCCP returned packet

This counter increments when the firewall receives a GRE-encapsulated packet back from a WCCP cache engine but cannot find a route to the original client (the source IP address in the decapsulated packet). When WCCP redirects client traffic to a cache engine, the cache engine may return the packet to the firewall for delivery to the destination server. The firewall must perform a route lookup for the client's IP address to determine the correct ingress interface and apply security policies before forwarding. This drop occurs in routed mode when that route lookup fails, typically because the client network is not in the routing table, the route was removed after redirection occurred, or VRF configuration prevents the lookup from succeeding. The cache engine and client may be on different interfaces within the same security context, requiring accurate routing information for proper packet handling.

Recommendation:

Verify that routes exist for all client networks that are subject to WCCP redirection. Use 'show route' to confirm the firewall has routes to the source IP addresses shown in packet captures of the dropped traffic. If using VRFs, ensure WCCP service groups and routing are configured consistently within the correct VRF context. Check for routing changes or flapping that might cause routes to disappear between the initial redirection and the cache engine's return of the packet. If the cache engine and clients are on different interfaces, confirm that routing between those networks is properly configured. In transparent firewall mode, this counter should not increment as the processing path differs. If drops persist with correct routing in place, collect packet captures on both the cache engine interface and client interface, along with 'show wccp' and 'show route' output, and contact Cisco TAC.

Syslogs:

None.

----------------------------------------------------------------

x-link2state

Packet dropped by SMTP X-Link2State detection

The packet was dropped because the SMTP inspection engine detected an X-Link2State header in the email traffic and the Network Analysis Policy is configured to drop packets containing this header. X-Link2State is a non-standard SMTP header historically associated with buffer overflow vulnerabilities in certain email clients (CVE-2005-0560). The SMTP inspector can be configured to disable detection, generate alerts only, or drop packets when this header is present. This counter increments when the drop action is configured and triggered.

Recommendation:

This drop is typically intentional security enforcement. Review your Network Analysis Policy SMTP preprocessor configuration to verify the X-Link2State setting matches your security requirements. If legitimate email traffic is being blocked, you can change the X-Link2State action from 'drop' to 'alert' or 'disable' in the SMTP inspection settings. Use packet tracer or packet capture with SMTP inspection debugging enabled to confirm the presence of X-Link2State headers in the dropped traffic. If drops are unexpected and no X-Link2State headers should be present in your environment, investigate the source of the email traffic for potential security concerns.

Syslogs:

None.

----------------------------------------------------------------

zta-src-translation-failure

Zero Trust Access source translation pool exhausted

The firewall dropped a packet destined for a Zero Trust Network Access application because the configured source translation pool has no available IP addresses or ports. ZTNA applications can be configured with a mapped source network object to translate client source addresses when accessing internal applications. This counter increments when all addresses in that pool are already in use by active connections, or when all available ports on those addresses are exhausted (for PAT configurations). This typically occurs when the pool is undersized for the number of concurrent users accessing ZTNA applications, or when connections are not timing out properly and holding translations longer than expected.

Recommendation:

Check the current pool utilization with 'show nat pool' to see how many translations are active versus the pool capacity. Review the mapped source network object configured for your ZTNA applications (visible in the ZTNA application configuration on FMC or via 'show running-config zero-trust' on FTD) and verify it contains sufficient IP addresses for your user population. For PAT pools, each IP address supports approximately 64,000 concurrent connections per destination. If the pool is consistently exhausted, add more IP addresses to the mapped source network object. Also check 'show xlate' to identify if stale translations are consuming pool resources—consider adjusting NAT timeout values if connections are being held unnecessarily long. If this occurs in a cluster, verify that port block allocation is functioning correctly across cluster members.

Syslogs:

None.

----------------------------------------------------------------

acl-drop

Flow denied by access control policy

This counter increments when a new connection attempt is blocked by an access control rule during flow creation. The device evaluates access control policies when the first packet of a connection arrives and denies the flow if no permit rule matches. This includes explicit deny rules, implicit deny-all rules at the end of access lists, and system-generated deny rules created by various features. Common scenarios include: interface access lists blocking traffic, user-based access lists applied through authentication (AAA/VPN), management-only or backup interfaces receiving through-traffic, IPsec-enabled interfaces receiving unencrypted traffic, and traffic denied by special lockdown policies (management lockdown, NVE lockdown, backup interface lockdown). The counter tracks flow-level denials—each blocked connection attempt increments it once, regardless of how many packets arrive for that connection. Both ingress and egress access list denials contribute to this counter.

Recommendation:

Check for corresponding syslog messages that identify which access list denied the traffic. For through-the-box TCP traffic, look for syslog 106023 (deny by interface access-group) or 106015 (TCP no connection). For VPN/AAA user filter denials, look for syslog 106103. For UDP traffic, check syslog 106023. Review the access list configuration on the ingress and egress interfaces to determine if the denial is intentional. If the traffic should be permitted, add an appropriate permit rule before the implicit deny. Note that some denials are expected and benign—for example, unsolicited inbound connection attempts from the Internet, or traffic arriving on management-only interfaces. If the counter increments rapidly from a single source, it may indicate a port scan or reconnaissance activity. Use packet capture with 'capture asp-drop acl-drop' to identify the specific traffic being denied. Remember that the counter shows the real (pre-NAT) addresses, not the translated addresses visible in interface captures.

Syslogs:

106023, 106015, 106100, 106103

----------------------------------------------------------------

acl-drop-reclassify

Flow denied by access control rule after application identification

This counter increments when a connection is terminated after application identification reveals that the traffic should be blocked by an access control policy rule. This occurs on FTD platforms when a flow is initially permitted based on IP addresses and ports, but application inspection subsequently identifies the protocol or application (for example, HTTP, SSH, or a specific web application). The access control policy is then re-evaluated with the discovered application context. If a deny rule matches the identified application, the flow is immediately terminated and this counter increments. This is normal behavior for application-aware access control policies that use application filters or conditions in deny rules.

Recommendation:

Review the access control policy to confirm that the deny rule is intentional. Use packet capture or connection events to identify which application was detected and which policy rule caused the drop. If the block is unintended, adjust the access control policy rule order or conditions—permit rules with application filters must be evaluated before deny rules to take effect. If the application identification is incorrect, consider tuning application detection or using custom application detectors. This counter does not indicate a configuration error; it reflects application-aware policy enforcement working as designed.

Syslogs:

Connection teardown events (302013, 302014, 302015, 302016, 302020, 302021) may be generated depending on the connection state when the application was identified and the flow was terminated.

----------------------------------------------------------------

asa-teardown

Flow removed by inspection engine or invalid TCP destination

The connection was removed for one of two reasons: (1) A TCP packet was received with a multicast destination IP address, which violates the TCP protocol specification and prevents connection state tracking. TCP is a unicast-only protocol and cannot establish connections to multicast addresses. (2) On FTD platforms with Snort inspection enabled, the Snort inspection engine explicitly requested flow removal through the internal backplane interface. This occurs when Snort determines the flow should be terminated based on inspection policy, application identification results, or resource management decisions.

Recommendation:

For multicast destination drops: Verify upstream routing and forwarding configuration to ensure TCP traffic is not being incorrectly directed to multicast addresses. Check for misconfigured load balancers or routing protocols that might be using multicast MAC addresses with TCP connections. For Snort-initiated removals on FTD: This is typically normal operation when inspection policy blocks an application or when Snort performs flow cleanup. Review Snort event logs and intrusion policy settings if legitimate traffic is being unexpectedly terminated. If the counter increments rapidly without corresponding policy blocks, collect a packet capture and troubleshooting bundle for analysis.

Syslogs:

None.

----------------------------------------------------------------

audit-failure

Legacy IDS signature matched with reset action

Traffic matched a signature in a legacy intrusion detection policy configured with the reset action, causing the flow to be terminated. This counter increments when the device detects attack patterns (such as TCP packets with invalid flag combinations, ICMP-based attacks, UDP bomb attacks, or IP fragmentation exploits) or informational reconnaissance activity (such as specific ICMP message types or DNS queries) that match signatures defined in an active policy created with the 'ip audit name' command. When the matching policy specifies 'reset' as one of its actions, the device tears down the associated flow and increments this counter. The legacy IDS feature operates independently of modern Snort-based inspection and uses a fixed set of predefined signatures that monitor for common network attacks and reconnaissance patterns at the data plane.

Recommendation:

Review your legacy IDS configuration to determine whether the reset action is appropriate for the signatures being matched. Use 'show ip audit count' to identify which specific signatures are triggering, and 'show running-config ip audit' to review your policy definitions. If the matched signature represents legitimate traffic in your environment (for example, ICMP redirects or specific DNS query patterns), either disable that signature using 'ip audit signature <number> disable' or remove the reset action from the policy with 'ip audit name <policy-name> {attack|info} action alarm' (omitting 'reset'). If the signature represents actual attack traffic, the drops are protective and expected. Note that this is a legacy feature; for modern deployments, consider migrating to Snort-based intrusion prevention policies which provide more granular control and up-to-date signature coverage.

Syslogs:

Varies by signature (each signature has an associated syslog message generated when the 'alarm' action is also configured)

----------------------------------------------------------------

bfd-flag-not-set

BFD flag not set for UDP BFD flow

This counter increments when the system detects UDP traffic on standard BFD ports (3784 for single-hop BFD, 3785 for BFD echo, or 4784 for multi-hop BFD) flowing from a dynamically created virtual access interface to its associated physical interface, but the traffic is not properly marked as legitimate BFD protocol traffic. Virtual access interfaces are created automatically for Dynamic Virtual Tunnel Interfaces (DVTI) in IPsec VPN deployments. The drop occurs during flow creation as a security validation to prevent non-BFD traffic from masquerading as BFD protocol traffic on these reserved ports. This check was strengthened to address a security vulnerability where traffic on BFD ports could incorrectly bypass access control lists.

Recommendation:

This drop typically indicates a configuration mismatch or software issue rather than a normal operational condition. First, verify that BFD is properly configured on the DVTI tunnel interfaces using the appropriate BFD template or interface-level BFD commands. Check that BFD sessions are established correctly with 'show bfd neighbors' and 'show bfd summary'. If BFD is not intentionally configured, investigate whether other applications or protocols are incorrectly using the reserved BFD UDP ports (3784, 3785, 4784) on the DVTI interfaces. Review any custom access control lists or service policies applied to the virtual template or tunnel-group that might affect BFD traffic. If the counter increments persistently despite correct BFD configuration, or if legitimate BFD sessions fail to establish, contact Cisco TAC with the output of 'show asp drop', 'show bfd neighbors detail', 'show vpn-sessiondb detail l2l', and a packet capture filtered for UDP ports 3784-3785.

Syslogs:

None

----------------------------------------------------------------

channel-closed

Cluster or HA link interface not ready

Packets were received on a cluster control link (CCL) or high-availability link interface that is not operational. This occurs when the interface is administratively down, has not completed initialization, or has detected a failure condition. The device drops these packets to prevent processing traffic on an interface that cannot reliably handle it. This is most commonly seen during cluster formation, when a CCL interface is being reconfigured, during interface state transitions (such as a member joining or leaving a cluster), or when the physical link is flapping. In high-availability deployments using UDP transport, the same counter increments when the HA link interface experiences similar conditions.

Recommendation:

Check the operational status of your cluster control link or HA link interface using 'show interface' and verify the interface is up and has completed initialization. If the interface is administratively down, bring it up with 'no shutdown'. For cluster deployments, use 'show cluster info' to verify cluster health and CCL connectivity between members. If the interface is physically up but this counter is incrementing, check for link flapping or hardware issues on the CCL or HA link. During normal cluster operations, brief increments during topology changes (member joins/leaves) or CCL interface reconfigurations are expected and benign. Sustained or frequent increments indicate an unstable CCL or HA link that requires investigation of the underlying physical connectivity, interface configuration, or hardware health.

Syslogs:

None.

----------------------------------------------------------------

children-limit

Parent flow exceeded maximum child connection limit

A parent connection has reached the maximum limit of 200 child connections and attempted to create an additional child connection. Child connections are secondary flows created by application inspection for protocols like FTP (data channels), SIP (media streams), H.323 (media channels), and similar applications that dynamically negotiate additional connections. This limit prevents a single parent connection from exhausting firewall memory or causing performance degradation. When this counter increments, new child connections for the affected parent are dropped while the parent connection itself remains active. This condition typically indicates either an application behaving abnormally (creating excessive secondary connections), a misconfigured client or server, or potentially a resource exhaustion attack attempting to overwhelm the firewall by forcing it to track an excessive number of related flows.

Recommendation:

First, identify which parent connection is hitting the limit by correlating the timestamp with syslog 210005, which logs the specific connection details. Examine whether the application behavior is legitimate—some applications under heavy load may create many secondary connections, but 200 is an unusually high number for normal operation. For FTP servers experiencing this issue, enable strict FTP inspection with 'inspect ftp strict' in the policy-map, which enforces RFC compliance and prevents malformed FTP commands from creating excessive data connections. Use 'set connection per-client-max' within a service policy to limit the total number of connections a single client can establish, preventing any single host from monopolizing connection resources. If the behavior appears malicious, investigate the source IP for signs of attack or compromise. If legitimate applications consistently hit this limit under normal operation, contact Cisco TAC to discuss your specific use case, as the 200-child limit is hardcoded and cannot be adjusted via configuration.

Syslogs:

210005

----------------------------------------------------------------

clean_for_vpn_stub

Existing flow removed to create VPN stub flow in cluster

This counter increments when the device removes an existing connection to prepare for creating a VPN stub flow in a clustered deployment. In cluster environments with distributed VPN mode, VPN traffic may be redirected between cluster members. When a unit receives a redirected VPN packet but finds an existing flow that conflicts with the required stub flow, it tears down the conflicting connection first. This typically occurs during flow ownership transitions, when cluster topology changes, or when bulk flow synchronization between cluster members is delayed. The cleanup ensures only one cluster member owns each flow and prevents double-owner scenarios where multiple units incorrectly believe they control the same connection. This is normal cluster VPN behavior and the affected traffic will be re-established through the new stub flow.

Recommendation:

This counter is expected in clustered deployments using distributed VPN mode and does not indicate a problem by itself. The original connection is torn down and traffic continues through the newly created stub flow. If you observe sustained high rates of this counter along with VPN traffic loss, verify cluster health and check for frequent cluster membership changes or control-link instability that could cause repeated flow ownership transitions. Review cluster status and ensure all members are stable. If VPN sessions are frequently moving between cluster members without topology changes, collect troubleshooting data and contact Cisco TAC for analysis.

Syslogs:

None.

----------------------------------------------------------------

closed-by-block-reset

Connection terminated by inspection engine block verdict

The inspection engine detected a policy violation and instructed the TCP proxy to terminate the connection with a reset. This occurs when traffic subject to deep packet inspection matches a blocking rule in the intrusion policy, file policy, or malware policy. The device operates a full TCP proxy for certain inspected connections, terminating the TCP session on both sides (client and server) and sending reset packets to cleanly tear down the connection. The counter increments once per blocked connection, not per packet.

Recommendation:

This counter is informational and reflects normal security policy enforcement. Review the intrusion events, file events, or connection events in the management center to identify which policy rule triggered the block. Common triggers include intrusion prevention system (IPS) rule matches with a 'drop and generate events' action, file blocks based on file type or malware detection, and application blocks. If legitimate traffic is being blocked, adjust the intrusion policy (set rules to alert-only or disable), modify file policy rules, or create exceptions for trusted applications or file types. No action is needed if the blocks align with your security policy.

Syslogs:

507003

----------------------------------------------------------------

closed-by-inspection

Flow closed by inspection engine

The device terminated a connection because an application inspection engine detected a protocol error, policy violation, or security concern that required closing the flow. This counter increments when inspection engines (such as those for DNS, SSL/TLS, DTLS, H.323, SIP, SCTP, ICMP, or STUN) proactively tear down a connection rather than simply dropping individual packets. Common triggers include malformed protocol messages, embedded address translation failures during NAT, encryption or decryption errors in SSL/TLS inspection, invalid ICMP codes, DNS protocol violations, or policy-based denials. The inspection engine determines that the connection cannot continue safely and terminates both directions of the flow. This is a normal security enforcement mechanism and indicates the inspection feature is actively protecting the network.

Recommendation:

Review the accompanying syslog messages (typically %ASA-3-507003) to identify which inspection engine closed the flow and the specific reason. Verify that the appropriate inspection policies are configured for the affected traffic types. If closures are unexpected, check for legitimate application behavior that may violate protocol standards or configured policies—for example, applications that embed private IP addresses in payloads when NAT is enabled, or clients using deprecated SSL/TLS versions. For SSL/TLS inspection, verify certificate trust chains and cipher suite compatibility. If the counter increments frequently for legitimate traffic, adjust the inspection policy to be less restrictive or disable inspection for trusted flows using class-maps and policy-maps. Use packet captures to examine the traffic that triggered the closure. This counter is informational and does not necessarily indicate a problem—it confirms that inspection is actively enforcing security policies.

Syslogs:

507003

----------------------------------------------------------------

cluster-ccl-backup

Cluster data packet received on backup unit

A data packet was received over the Cluster Control Link on a unit that holds only a backup copy of the flow, when the packet should have been processed by the flow owner or director unit. This typically indicates stale flow state where the backup unit's flow information has not been updated to reflect current cluster topology. Common triggers include: cluster membership changes (unit leaving or joining), failover events, interface PAT configurations where ownership changes dynamically, or loss of flow deletion messages due to hardware buffer exhaustion or internal queue overflows. The backup unit correctly drops the packet because it cannot process traffic for flows it does not own.

Recommendation:

This counter incrementing during or immediately after cluster topology changes (unit removal, failover, or join operations) is expected and typically self-correcting as flow state synchronizes. If the counter grows continuously during steady-state operation, investigate: (1) Check for hardware buffer drops using 'show interface' — sustained 'no buffer' drops can prevent flow deletion messages from reaching backup units, leaving stale flows. (2) Review 'show asp drop' for 'dispatch-queue-limit' drops, which indicate internal queue overflows that can also block flow updates. (3) For interface PAT configurations, verify that PAT pool ownership is stable across cluster members. (4) If drops persist, identify the affected flows and clear them manually using 'clear conn address <ip>' to force flow re-establishment with correct ownership. Contact TAC if drops continue after clearing stale flows, especially if correlated with specific traffic patterns (DNS, transparent mode inline-sets) or NAT configurations.

Syslogs:

None.

----------------------------------------------------------------

cluster-ccl-bad-unxlate-redirect

Cluster member dropped NAT untranslate redirect packet that matched a director stub flow

A cluster member received a NAT untranslate redirect request from another member over the cluster control link, but the packet matched a director stub flow rather than a full flow. This indicates the sending member's dynamic PAT pool ownership information is out of sync with the receiving member. In a cluster, each member owns specific port blocks within PAT pools. When return traffic arrives, members redirect packets to the pool owner for untranslation. If the sender's pool ownership table is stale—typically after a cluster membership change, member failure, or during pool rebalancing—it may redirect packets to a member that no longer owns that port block. The receiving member detects this mismatch and drops the packet to prevent redirect storms. If the receiving member is the cluster master, it sends a pool ownership update back to the sender to resynchronize its state. This drop is expected during cluster convergence after topology changes and should be transient.

Recommendation:

This counter typically increments briefly after cluster membership changes (member joins, leaves, or fails) or during NAT pool rebalancing, and should stop once pool ownership information synchronizes across all members. If the counter increments continuously or for an extended period, verify cluster health with 'show cluster info' and check for flapping members or control link issues. Review 'show asp drop' for related counters like 'nat-no-xlate-to-pat-pool' or 'cluster-ccl-backup'. Examine connection logs to identify affected flows—DNS queries and from-the-box traffic are common triggers. If the problem persists despite stable cluster membership, collect 'show tech-support' and contact Cisco TAC, as this may indicate a timing issue in pool ownership synchronization.

Syslogs:

None.

----------------------------------------------------------------

cluster-cflow-clu-closed

Replicated stub flow removed after owner closed connection

In a cluster deployment, this counter increments when a director or backup unit receives a delete notification from the connection owner unit and removes its local stub flow. Stub flows are lightweight flow replicas maintained on non-owner units to enable fast forwarding and failover. When the owner unit closes a connection (due to normal teardown, timeout, reset, or policy action), it sends delete messages to all units holding stub flows for that connection. This counter tracks the successful removal of those stub flows and is part of normal cluster flow synchronization. The counter increments for every replicated stub flow torn down in response to owner-initiated closure, and should correlate with connection teardown activity on owner units.

Recommendation:

This counter reflects normal cluster operation and typically requires no action. Steady increments indicate healthy flow replication and cleanup as connections close across the cluster. However, investigate if: (1) the counter grows disproportionately compared to new connection rates, which may indicate premature flow teardowns or instability in flow ownership; (2) you observe connection failures or asymmetric traffic issues coinciding with counter spikes, which could point to cluster control link problems or flow synchronization delays; or (3) stub flows are not being cleaned up (check 'show conn' output for stale entries). Compare this counter with 'show cluster info' statistics to verify director/backup/owner role distribution is balanced. If stub flow cleanup appears delayed or connections are failing, verify cluster control link health and check for defects related to flow replication timing.

Syslogs:

None

----------------------------------------------------------------

cluster-cflow-clu-timeout

Cluster stub flow removed due to missing owner updates

A cluster member holding a stub flow (director, backup, or forwarder role) has removed the flow because it stopped receiving periodic state updates from the flow owner. In clustering, the flow owner sends update messages at regular intervals (default 15 seconds, configurable via clu-keepalive-interval) to keep director and backup units synchronized. When these updates stop arriving for longer than the idle threshold (typically 4 times the keepalive interval, or 60 seconds by default), the stub flow is considered stale and removed. This typically occurs when: the flow owner has left the cluster unexpectedly, cluster control link (CCL) communication is disrupted or experiencing high packet loss, the owner unit has failed or reloaded without sending proper flow deletion messages, or there is a version mismatch during a rolling upgrade causing incompatible message formats. The counter may also increment during normal cluster topology changes when a unit departs and its flows are being cleaned up.

Recommendation:

Review cluster health and CCL connectivity. Check 'show cluster info' to verify all expected units are present and in a healthy state. Examine 'show cluster info trace' for recent member departures or join/leave events. If the counter is incrementing steadily during normal operation, investigate CCL link quality—check for packet loss, high latency, or interface errors on the cluster control link interfaces. Verify that the clu-keepalive-interval is appropriate for your network conditions; in high-latency or inter-site deployments, consider increasing the interval to prevent false timeouts. During rolling upgrades, temporary increments are expected as units running different versions may have incompatible flow synchronization message formats—ensure all units are upgraded to the same version promptly. If specific flows are repeatedly timing out, use 'show conn detail' to identify the affected connections and check if the original owner unit is still in the cluster. For persistent issues with stale flows accumulating, manually clear them with 'cluster exec clear connection' and investigate the root cause of owner communication failure.

Syslogs:

None

----------------------------------------------------------------

cluster-cflow-isakmp-owner-closed

Cluster VPN stub flow removed on ISAKMP owner

This counter increments when a cluster unit receives an ISAKMP (IKE) packet redirected from another cluster member and removes a temporary stub flow before establishing the full VPN flow. This occurs during normal cluster operation with VPN NAT Traversal (NAT-T) when the cluster is negotiating which unit will own the VPN session. When a forwarding unit initially receives ISAKMP traffic (UDP port 500 or 4500), it may create a temporary stub flow while determining the correct owner. Once the designated owner unit receives the redirected ISAKMP packet, it cleans up any existing stub flow so it can establish itself as the authoritative flow owner for that VPN session. The packet itself is dropped as part of this ownership transition, but the VPN negotiation continues normally.

Recommendation:

This counter incrementing is expected behavior in cluster deployments with VPN and does not indicate a problem. Each increment represents a successful cluster flow ownership negotiation for VPN NAT-T traffic. No action is required unless you observe VPN connection failures coinciding with these drops. If VPN sessions are failing to establish, verify cluster health, check that all cluster members can communicate over the cluster control link, and review VPN configuration for any mismatches between cluster members. This counter should correlate with VPN session establishment activity in the cluster.

Syslogs:

None.

----------------------------------------------------------------

cluster-cflow-nat-pool-removed

Cluster flow removed due to deleted NAT pool

This counter increments when a cluster member removes a director or backup stub flow because the NAT pool referenced by that flow no longer exists in the configuration. In a cluster deployment, each connection has an owner unit that maintains the full flow state, plus director and backup units that maintain stub flows for redundancy and forwarding. When a NAT pool is deleted from the configuration, the cluster performs bulk synchronization to clean up any stub flows that were tracking connections using addresses from that pool. This is expected behavior during NAT configuration changes and ensures that stale flow state does not persist after the underlying NAT resources have been removed.

Recommendation:

This counter is informational and indicates normal cluster housekeeping after NAT configuration changes. Increments typically occur when you remove or modify NAT rules that use address pools, particularly dynamic PAT pools. The affected connections will be re-established if they are still active and match current NAT policy. If you see unexpected increments without recent NAT configuration changes, verify that all cluster members have synchronized NAT configurations using 'show running-config nat' and 'show nat pool cluster'. Configuration mismatches between cluster members can cause repeated flow cleanup cycles. No action is required for increments that correlate with intentional NAT policy changes.

Syslogs:

None

----------------------------------------------------------------

cluster-cflow-stale-clu-closed

Tentative cluster flow removed due to owner mismatch

A temporary cluster flow placeholder (stub) was removed because the flow owner information received in a forwarded packet did not match the expected owner. In cluster deployments, when a node forwards traffic for a new connection, it creates a tentative stub flow while waiting for confirmation from the flow owner. If the owner reply indicates a different owner than expected—typically due to timing issues during cluster synchronization, membership changes, or flow ownership transitions—the stub is deleted to maintain consistency. This counter increments as part of normal cluster flow state reconciliation and does not indicate packet loss; the connection will be re-established with the correct owner.

Recommendation:

This counter is informational and reflects normal cluster flow synchronization behavior. Occasional increments are expected, especially during cluster topology changes (units joining or leaving), flow ownership transitions, or when cluster control link messages arrive out of order. Investigate only if this counter increases rapidly alongside connection failures or packet drops on the cluster control link. Check 'show cluster info' for membership stability and 'show asp drop' for related cluster drop counters (cluster-ccl-backup, cluster-no-owner). If traffic loss occurs with high values of this counter, verify cluster control link health and check for asymmetric routing issues that may cause excessive flow forwarding between cluster members.

Syslogs:

None.

----------------------------------------------------------------

cluster-convert-to-dirbak

Flow role converted from forwarding to director or backup

A cluster unit removed a forwarding or redirect stub flow to transition into a director or backup role for that connection. In ASA and FTD clustering, each connection has an owner unit that processes the traffic, a director unit that coordinates the flow, and optionally a backup unit for redundancy. When a unit initially receives packets for a connection it does not own, it creates a forwarding stub to redirect those packets over the cluster control link to the owner. If the unit is subsequently elected as the director or backup for that same connection (typically during cluster topology changes, member joins or leaves, or flow rebalancing), it must first remove the forwarding stub before establishing the new director or backup flow state. This counter increments each time that conversion occurs.

Recommendation:

This counter is informational and reflects normal cluster operation. It typically increments during cluster membership changes (units joining or leaving), flow ownership rebalancing, or when the cluster topology changes and flow roles are reassigned. No action is required. If this counter increments rapidly or continuously without corresponding cluster events, verify cluster control link stability and check for frequent cluster membership flapping using 'show cluster info' and 'show cluster history'. Persistent high values may indicate cluster instability that should be investigated.

Syslogs:

None directly associated. Related syslogs include %ASA-7-785001 (flow ownership moved) and %ASA-6-302026 (stub flow creation).

----------------------------------------------------------------

cluster-ctp-punt-channel-missing

Flow dropped during cluster bulk sync due to missing authentication proxy state

A connection requiring HTTP or HTTPS authentication proxy (cut-through proxy) was dropped during cluster bulk synchronization because the authentication state was not properly replicated to the receiving cluster member. This occurs when a cluster control node leaves or fails before fully synchronizing authentication proxy rules and state to other members. The authentication proxy mechanism uses a specialized processing path that must be present in the flow's processing chain; when this path is missing during flow restoration, the connection cannot be safely established and is dropped to prevent incomplete authentication state.

Recommendation:

This drop is a protective measure to prevent connections from bypassing authentication. Users will be prompted to re-authenticate, or their client applications will automatically retry the connection. If this counter increments frequently, investigate cluster control link stability and verify that cluster members are not leaving unexpectedly. Check for cluster control link packet loss or interface flapping using 'show cluster info' and 'show interface' on the cluster control link interface. Review cluster health with 'show cluster info' to identify members joining and leaving. If authentication proxy is not required, consider disabling it to avoid this synchronization dependency. For persistent issues with cluster member stability, collect 'show tech-support' and contact Cisco TAC.

Syslogs:

302014

----------------------------------------------------------------

cluster-dir-removed-dup-owner

Duplicate flow owner removed by cluster director

In a cluster deployment, this unit detected that multiple cluster members believe they own the same connection (duplicate owner condition). The cluster resolved the conflict by comparing connection creation timestamps and removing the newer duplicate flow from this unit. The director unit orchestrated this cleanup to ensure only one unit owns each connection. This counter increments in two scenarios: (1) when this unit receives a flow synchronization message from another owner and determines its local flow is newer based on timestamp comparison, or (2) when the director explicitly instructs this unit to delete a duplicate owner flow during ownership transitions. Duplicate owner conditions can occur during normal cluster operations such as member join/rejoin events, topology changes, upgrades, or timing-sensitive scenarios where packets arrive at different units before flow synchronization completes (for example, ICMP replies reaching the director before the owner's flow creation message). This is particularly common with fragmented traffic or when the flow owner is also acting as director.

Recommendation:

This counter is informational and indicates normal cluster flow ownership resolution. No action is required. The cluster automatically resolves duplicate owner conditions by keeping the flow that was created first (based on timestamp) and removing newer duplicates. If this counter increments excessively during stable cluster operation (not during member join/leave events), verify cluster control link health and check for asymmetric routing or load balancing issues that might cause the same connection to be established on multiple units simultaneously. Review cluster health with 'show cluster info' and cluster control link statistics. If duplicate owner conditions correlate with traffic disruption, collect troubleshooting bundles from all cluster members and contact Cisco TAC.

Syslogs:

None.

----------------------------------------------------------------

cluster-director-change

Director or backup flow removed due to cluster topology change

A unit holding a director or backup copy of a flow has removed that copy because the cluster topology changed and this unit is no longer assigned the director or backup role for the flow. This occurs during periodic bulk synchronization when the cluster detects that director or backup assignments have shifted—most commonly when a new unit joins the cluster or an existing unit rejoins after being removed. The unit that owns the flow will send updated state to the newly assigned director and backup units. This counter reflects normal cluster rebalancing and does not indicate a problem with the flow itself; the flow owner continues to process traffic and will synchronize state with the new director.

Recommendation:

This counter is informational and reflects expected cluster behavior during membership changes. Occasional increments during unit joins, removals, or cluster formation are normal. If this counter increments continuously without cluster topology changes, or if you observe connection blackholing (traffic dropped with no flow owner), check for stale director or backup flows using 'show conn detail' and look for flows where the owner field is invalid. In rare cases, stale director or backup flows may need to be cleared manually with 'cluster exec clear conn' if they persist and cause traffic drops. Review cluster health with 'show cluster info' to ensure all units are stable and the control link is functioning properly.

Syslogs:

None.

----------------------------------------------------------------

cluster-director-closed

Connection removed on backup/forwarder unit after director closed flow

This counter increments when a cluster member that is not the connection owner (typically a backup or forwarder unit) receives a delete message from the director unit indicating that the connection has been closed. In ASA/FTD clustering, connections are owned by one unit (the owner) but replicated to other units for redundancy. The director unit coordinates connection state across the cluster. When the director determines a connection should be torn down—due to normal termination, timeout, or policy changes—it sends delete messages to all units holding replicas of that connection. Each non-owner unit that receives this message and removes its local replica increments this counter. This is normal cluster operation and reflects proper synchronization of connection teardown across cluster members.

Recommendation:

This counter incrementing is expected behavior in a healthy cluster and indicates that connection state is being properly synchronized. The counter should roughly correlate with connection teardown activity on the director unit. If this counter is incrementing but connections appear stuck or traffic is being dropped, check for stale director or backup flows using 'show conn' and look for flows without valid owners. In rare cases (such as those described in defects CSCvw31569 and CSCwt77571), incomplete flow teardown can leave orphaned director/backup flows that blackhole traffic; if suspected, use 'cluster exec clear conn address <IP>' to manually remove stale flows. Monitor 'show asp drop' for related counters like 'cluster-ccl-backup' which may indicate forwarding to invalid owners. This counter incrementing alone is not a problem—it confirms that cluster flow replication and deletion is working as designed.

Syslogs:

None

----------------------------------------------------------------

cluster-drop-on-data-node

Packet dropped on data node per centralized processing rule

In Layer 3 clustering deployments, certain traffic types are received by all cluster members but must be processed only by the control node to maintain consistency. These include routing protocol packets (OSPF, EIGRP, BGP, PIM, RIP), multicast control traffic, site-to-site VPN in centralized mode, and other control-plane protocols. When such packets arrive on a data node, a classification rule identifies them and drops them locally, ensuring only the control node processes them. This counter increments on data nodes when these centralized-processing packets are correctly dropped. In Layer 2 clusters, this mechanism is not used because the upstream switch directs such traffic only to the control node.

Recommendation:

This counter is informational and indicates normal operation in Layer 3 clusters. The packets are not lost—the control node receives and processes identical copies. If this counter increments unexpectedly: (1) Verify you are running a Layer 3 cluster (routed interfaces between units). (2) For site-to-site VPN traffic, confirm 'vpn-mode centralized' is configured (this is the default). (3) Check that routing protocols and multicast are functioning correctly on the control node using 'show route' and 'show cluster info'. (4) If VPN sessions fail with this counter incrementing, verify that fragmented IKE packets and ESP packets are being forwarded to the control node—see CSCwp05532 and CSCwt93955 for known issues with control-plane ACLs blocking centralized VPN traffic on data nodes. No action is required if the control node is processing the traffic successfully.

Syslogs:

None.

----------------------------------------------------------------

cluster-dup-owner-to-dir

Duplicate flow owner detected; transitioning to director role

This counter increments when the cluster detects that two members both believe they own the same connection. In ASA/FTD clustering, each connection is assigned an owner (the member processing traffic), a director (coordinating ownership decisions), and a backup (maintaining state for failover). When a duplicate owner is detected—typically during cluster membership changes, unit joins or leaves, or flow mobility events—the conflict is resolved by having one member delete its owner flow state and transition to the director role instead. This ensures only one member actively processes the connection while maintaining proper state coordination across the cluster.

Recommendation:

This counter is informational and reflects normal cluster conflict resolution. Small increments during cluster topology changes (member joins, leaves, or failovers) are expected behavior. However, continuously increasing values during stable cluster operation may indicate timing issues with cluster control link communication or flow replication delays. If you observe persistent increments without topology changes, verify that the cluster control link has sufficient bandwidth and low latency, check for packet loss on the cluster control link interface, and ensure all cluster members are running the same software version. Contact Cisco TAC if the counter increases rapidly or correlates with connection failures.

Syslogs:

None directly associated. May occur near syslog 785001 (flow ownership changes) during cluster topology events.

----------------------------------------------------------------

cluster-mcast-owner-change

Multicast flow removed after cluster topology change

A multicast flow was removed from this cluster unit because it is no longer the designated owner for that flow. In clustering deployments with multicast traffic, each multicast data flow is assigned to a specific owner unit. For Layer 3 cluster interfaces, only the control (master) unit can own multicast data flows. When cluster topology changes occur—such as a unit joining or leaving the cluster, or a control unit election—multicast flow ownership may be reassigned. During periodic bulk synchronization maintenance, each unit evaluates its multicast flows and removes any that should now be handled by a different unit. The flow will be recreated on the correct owner unit when new multicast traffic arrives. This counter increments on the unit that previously owned the flow and is now relinquishing it.

Recommendation:

This counter is informational and indicates normal cluster operation during topology changes. Multicast flows are being correctly redistributed to their new owner units. No action is required unless you observe multicast traffic loss that persists after the cluster stabilizes (typically within seconds of the topology change). If multicast forwarding does not recover, verify that the cluster control unit is stable, PIM adjacencies are established on all cluster units, and multicast routing tables are populated correctly on the new owner. For Layer 2 (spanned EtherChannel) cluster deployments, each receiving unit owns its multicast flows; this counter is primarily relevant to Layer 3 (individual interface) clustering.

Syslogs:

None.

----------------------------------------------------------------

cluster-mobility-backup-removed

Backup flow removed after flow mobility operation

This counter increments when a cluster member removes a backup or site-backup stub flow following a flow mobility operation. Flow mobility occurs when LISP (Locator/ID Separation Protocol) detects that an endpoint has moved between cluster sites and triggers the cluster to relocate flow ownership to a unit closer to the endpoint's new location. After the ownership transfer completes, the cluster recalculates which units should maintain director, backup, and site-backup roles for the relocated flow. If the new flow owner and director are located on different cluster nodes or in different sites, certain backup stub flows become redundant and are removed. This is normal cluster housekeeping during inter-site flow mobility events.

Recommendation:

This counter is informational and indicates expected behavior in inter-site cluster deployments with flow mobility enabled (configured via 'cluster flow-mobility lisp' and applied through service policies). The counter should increment only when endpoints move between sites and trigger flow ownership changes. If this counter increments without flow mobility configured, or if it increments excessively during stable network conditions, verify that LISP endpoint mobility events are legitimate and that cluster site assignments are correct. Review syslog 785001 messages to correlate flow ownership changes with this counter. No action is required for occasional increments during normal endpoint mobility.

Syslogs:

785001

----------------------------------------------------------------

cluster-mobility-fwder-removed

Redundant forwarder flow removed after cluster flow mobility

This counter increments when a cluster member removes a redundant forwarder flow after completing a flow mobility operation. Flow mobility occurs when the cluster flow-mobility feature is enabled and a LISP endpoint identifier (EID) notification indicates that a server or endpoint has moved to a different cluster site. When the flow ownership is reassigned to a unit closer to the new endpoint location, the cluster recalculates which units need to maintain director, backup, and forwarder roles for that flow. A unit that was previously acting as a forwarder may discover that it will now become a director or backup for the moved flow. In this scenario, the old forwarder flow becomes obsolete because it lacks proper lookup state and would incorrectly appear with identity interface information after the move completes. The cluster removes this stale forwarder flow to prevent inconsistent flow state across the cluster. This counter is specific to inter-site (inter-data-center) cluster deployments with LISP-based flow mobility enabled.

Recommendation:

This counter is informational and indicates normal cluster flow mobility operation. It confirms that the cluster is correctly cleaning up redundant forwarder flows when endpoint mobility events trigger flow ownership changes. No action is required. If you observe this counter incrementing, verify that: (1) the 'cluster flow-mobility lisp' feature is intentionally enabled in your configuration, (2) LISP EID-notify messages are being received for endpoint mobility events, and (3) flows are successfully moving to the new owner units (check syslog 785001 for flow ownership changes). If flows are not moving as expected or connectivity is disrupted during mobility events, review the cluster flow mobility configuration and LISP integration. For troubleshooting flow mobility issues, use 'show cluster info flow-mobility' to view mobility statistics and 'show conn detail' to verify flow roles (director/backup/forwarder) across cluster members.

Syslogs:

785001

----------------------------------------------------------------

cluster-mobility-owner-2-dir

Flow ownership transferred during LISP mobility event

This counter increments when a cluster member transitions from being both the flow owner and flow director to being only the flow director, triggered by LISP-based flow mobility. This occurs in inter-site clustering deployments when an endpoint (server or client) physically moves between data centers and LISP detects the location change via EID-Notify messages. The cluster automatically relocates flow ownership to a member closer to the endpoint's new location to avoid traffic tromboning, while the original unit retains its director role to coordinate flow state across the cluster. The affected flow is removed from the local unit and recreated on the new owner.

Recommendation:

This counter is informational and indicates normal operation of the LISP flow mobility feature in inter-site clusters. Increments occur when endpoints move between sites and the cluster is configured with 'cluster flow-mobility lisp' or per-class 'flow-mobility lisp' policies. You should see corresponding syslog 785001 messages identifying the specific flows being moved. No action is required unless you observe connection disruptions during mobility events, in which case verify LISP EID-Notify messages are being received correctly and that the Cluster Control Link between sites has sufficient bandwidth. If flow mobility is not expected in your deployment, verify whether the feature is intentionally enabled.

Syslogs:

785001

----------------------------------------------------------------

cluster-mobility-owner-removed

Flow ownership transferred to another cluster member

A flow was removed from this cluster unit after ownership was successfully transferred to another cluster member. This occurs during cluster flow rebalancing operations, most commonly when LISP-based flow mobility detects that an endpoint has moved to a different data center site and relocates the flow owner to optimize traffic paths. It also occurs when cleaning up hardware-offloaded IPsec plaintext flows after ownership changes. The old owner unit removes its local flow state after the new owner confirms it has taken over the flow.

Recommendation:

This counter is informational and indicates normal cluster operation. Flow mobility ensures optimal traffic forwarding by moving flow ownership closer to active endpoints, avoiding unnecessary traffic tromboning across the cluster control link. No action is required. If you see this counter incrementing, check syslog 785001 for details about which flows are being moved and the reason for the transfer. Unexpected high rates may indicate frequent LISP endpoint mobility events or cluster topology changes.

Syslogs:

785001

----------------------------------------------------------------

cluster-owner-2-dir

Flow deleted to transition from owner to director role

This counter increments when a cluster unit receives a forced flow creation request from another unit that now owns the flow. The local unit deletes its existing owner flow to make way for creating a director flow in its place. This occurs during normal cluster flow role transitions, such as when flow ownership moves between units due to load balancing, topology changes, or unit rejoins after a failure. In a cluster, each flow has three roles: the owner (processes the traffic), the director (coordinates the flow), and backups (maintain state). When ownership shifts, the former owner must transition to the director role by removing its owner flow and creating a director flow for the same connection.

Recommendation:

This counter is informational and reflects normal cluster operation. The behavior is expected during cluster topology changes, unit joins or leaves, flow mobility events, and load rebalancing. No action is required unless the counter increments excessively (thousands per minute), which may indicate cluster instability, frequent unit flapping, or misconfigured load distribution. If the counter grows rapidly, check cluster health with 'show cluster info', verify the cluster control link is stable, and review recent cluster membership changes in the logs. Occasional increments during maintenance windows or controlled failovers are normal.

Syslogs:

None.

----------------------------------------------------------------

cluster-owner-2-fwd

Flow owner instructs unit to replace full flow with forwarder stub

In a cluster deployment, this counter increments when a unit receives a forced forwarding message from another cluster member that owns the same connection. The receiving unit has already created a full flow for the connection, but the actual flow owner is a different cluster member. To resolve this ownership conflict, the owner sends a force message instructing this unit to delete its full flow and replace it with a lightweight forwarder stub flow. The forwarder stub will redirect future packets for this connection over the cluster control link to the true owner. This typically occurs during cluster topology changes, load rebalancing, or when packets from the same connection initially arrive at different cluster members before ownership is established. The drop represents the removal of the conflicting full flow; traffic continues normally via the newly created forwarder stub.

Recommendation:

This counter is informational and indicates normal cluster flow ownership resolution. The behavior is expected during cluster member joins, leaves, or rebalancing operations. Traffic is not impacted—packets are redirected to the correct owner via the forwarder stub. If this counter increments continuously during stable cluster operation, verify that the cluster control link is healthy and that all members have consistent hash table synchronization. Persistent increments may indicate cluster control link congestion or asymmetric routing causing repeated ownership conflicts.

Syslogs:

None.

----------------------------------------------------------------

cluster-parent-owner-left

Pinhole flow removed during cluster master election

A dynamically opened pinhole flow was removed during cluster bulk synchronization because the parent flow's owner is no longer valid. This occurs in clustered Firewall Threat Defense deployments when a master election or master change event takes place. Application inspections (such as SIP, H.323, FTP, RTSP, and others) dynamically create pinhole flows to permit return traffic or related data channels. During cluster topology changes, the system performs bulk synchronization to reconcile flow state across all cluster members. If a pinhole flow's parent connection no longer has a valid owner assignment—typically because the unit that owned the parent flow has left the cluster or the master role has changed—the pinhole is removed as part of this cleanup process.

Recommendation:

This counter is informational and indicates expected behavior during cluster master elections or topology changes. Pinhole flows will be re-established by the application inspection engines when new traffic arrives after the cluster stabilizes. If this counter increments frequently, investigate cluster stability: check for repeated master elections using 'show cluster info' and 'show cluster history', verify cluster control link health, and review cluster member status. Persistent cluster instability may indicate control link issues, configuration mismatches, or resource exhaustion on cluster members. For applications with long-lived sessions that rely on pinholes (such as SIP or H.323), brief service interruption during master changes is expected; ensure application timeout and retry mechanisms can handle temporary connection loss.

Syslogs:

302014

----------------------------------------------------------------

cluster-pinhole-control-node-change

Centralized pinhole flow removed during control node change

A pinhole flow was removed during cluster bulk synchronization because the cluster control node changed. Pinhole flows are temporary openings created by application inspection (such as FTP, TFTP, or SIP) to allow secondary data connections. When these pinholes are configured to run only on the control node (centralized mode), they cannot be transferred to a new control node during failover or election. The system removes these flows during bulk sync and will recreate them as needed when the application establishes new secondary connections. This counter increments during control node elections, manual control node changes, or when a unit becomes the control node.

Recommendation:

This counter is informational and indicates expected behavior during cluster control node transitions. The removed pinhole flows will be automatically recreated when applications attempt to establish new secondary connections. If you observe application connectivity issues (such as FTP data channel failures) immediately after a control node change, allow time for the applications to re-establish their control connections and create new pinholes. For applications with long-lived control connections (like SIP), existing sessions may need to be re-registered. If secondary connections consistently fail after control node changes, verify that application inspection is properly configured and that the new control node has sufficient resources. No action is required for occasional increments during planned maintenance or failover events.

Syslogs:

302014

----------------------------------------------------------------

cluster-redirect

Stub forwarding flow terminated after cluster redirect

This counter increments when a temporary stub forwarding flow is removed after successfully redirecting packets to the correct cluster member. In clustered deployments, when a packet arrives at a unit that does not own the connection, the receiving unit creates a lightweight stub flow and forwards the packet over the cluster control link to the owner. When this stub flow is later cleaned up, this counter increments. This is normal cluster operation for asymmetric traffic patterns where packets for the same connection arrive at different cluster members. The counter reflects flow cleanup activity, not packet loss—the packets were successfully forwarded before the stub flow was removed.

Recommendation:

This counter is informational and indicates normal cluster operation. Incrementing values confirm that asymmetric traffic is being handled correctly—packets arriving at non-owner units are being redirected to the appropriate cluster member over the cluster control link. No action is required. If you see this counter growing alongside actual packet drops or connection failures, investigate cluster control link health, flow ownership distribution, and load balancing configuration. On Firepower 4200 series platforms, consider enabling hardware offload for cluster-redirected flows using the 'flow-offload cluster-redirect' command to improve performance for asymmetric traffic.

Syslogs:

None.

----------------------------------------------------------------

cluster-removed-stale-stub

Stale stub flow removed after cluster ownership change

In a cluster deployment, this counter increments when a unit removes a stub flow that references an outdated connection owner. Stub flows are lightweight forwarding entries maintained on director, backup, and forwarder nodes to redirect traffic to the unit that owns the full connection state. When cluster membership changes—such as a node leaving, joining, or during load rebalancing—connection ownership may shift to a different unit. The new owner broadcasts deletion messages to all cluster members that might hold stale stub flows pointing to the previous owner, ensuring consistent forwarding state across the cluster. This counter tracks successful cleanup of these outdated stub flows and is a normal part of cluster state synchronization during topology changes.

Recommendation:

This counter is informational and indicates normal cluster operation during membership changes or rebalancing events. Increments are expected when nodes join or leave the cluster, during manual rebalancing operations, or after failover events. No action is required unless the counter increments continuously without corresponding cluster topology changes, which may indicate instability in cluster membership. If the cluster is stable but this counter continues to increment rapidly, check cluster control link health, verify consistent configuration across all members, and review cluster health status. For persistent issues with stable cluster topology, collect troubleshooting bundles from all cluster members and contact Cisco TAC.

Syslogs:

None.

----------------------------------------------------------------

conn-limit-exceeded

Connection limit exceeded

A new connection attempt was denied because it would exceed a configured connection limit in a service policy. This occurs when traffic matching a class-map has reached the maximum number of concurrent connections allowed by the policy-map action. The limit may be a global maximum for all matching traffic, a per-client maximum restricting how many connections a single source IP can establish, or an embryonic connection limit for incomplete TCP handshakes. The counter increments both when new connection attempts are rejected at flow creation time and when existing connections are torn down due to limit enforcement. This mechanism protects the firewall and backend servers from resource exhaustion by enforcing connection quotas on a per-traffic-class basis.

Recommendation:

Check the service policy configuration to identify which connection limit was exceeded. Use 'show service-policy' to view current connection counts against configured limits for each traffic class. If the limit is being reached legitimately due to high traffic volume, consider increasing the conn-max or per-client-max values in the policy-map configuration. If a single client is consuming excessive connections, verify whether the per-client-max limit is appropriate or if the client behavior indicates a misconfiguration or attack. Review 'show conn' output to identify which hosts are establishing the most connections. Note that in older software versions, half-closed TCP connections may not be counted correctly toward limits, and connection counters can occasionally become negative due to accounting bugs; if you observe negative counts in 'show service-policy' output, contact Cisco TAC. On multi-core platforms, ensure you are running a recent software version to avoid false limit-exceeded events that can occur due to per-core counter synchronization issues.

Syslogs:

201011

----------------------------------------------------------------

connection-timeout

Connection Timeout

This counter increments when a connection is removed because no traffic has been observed for the configured idle timeout period. Each protocol has its own configurable timeout value (TCP defaults to 1 hour for established connections, UDP and ICMP have shorter defaults). When the idle timer expires without any packets traversing the connection, the firewall tears down the connection and logs the appropriate teardown message. This is normal connection lifecycle management and represents expected cleanup of inactive sessions.

Recommendation:

This counter typically indicates normal operation and requires no action. The firewall is cleaning up idle connections as designed. However, investigate further if: (1) users report unexpected disconnections of active sessions—this may indicate timeout values configured too low for the application's keepalive behavior, or a software defect where active connections are incorrectly timing out; (2) the counter is incrementing for connections that should remain idle longer—adjust timeout values using the 'timeout' command for the specific protocol; (3) you are running software with known timeout-related defects—check for applicable bugs, particularly if using SSL decryption, early application detection, inline interface pairs, or flow offload features. Review the associated teardown syslogs to identify which connections are timing out and verify the timeout configuration matches your application requirements.

Syslogs:

302014, 302016, 302018, 302021

----------------------------------------------------------------

ctm-crypto-request-error

Crypto context unavailable for SSL/TLS or DTLS session

This counter increments when the system cannot retrieve the cryptographic context needed to decrypt an SSL/TLS or DTLS packet. The crypto context contains the session keys, cipher state, and other parameters required for decryption. This error indicates an internal inconsistency where the crypto subsystem has lost access to the session's cryptographic state, even though the session itself still exists. This can occur during SSL VPN (AnyConnect) connections, TLS proxy sessions, or DTLS VPN traffic when the hardware crypto accelerator or software crypto path cannot locate or access the stored session context. For DTLS sessions, if the handshake has not yet completed when this error occurs, the connection is terminated; for established sessions, the individual packet is dropped but the connection may continue if subsequent packets succeed.

Recommendation:

This counter typically indicates a transient internal state issue during high SSL/TLS or DTLS session load. Check the 'show crypto protocol statistics ssl' output to identify whether SSL or DTLS sessions are affected and review session establishment rates. If the counter increments during periods of high VPN connection establishment (many simultaneous AnyConnect logins), this may indicate the crypto subsystem is temporarily unable to keep up with session state management. For hardware platforms with crypto accelerators (Firepower 1000/2100/4100/9300 series, ASA 5500-X with AES-NI), verify the accelerator is functioning correctly with 'show crypto accelerator statistics'. If drops are persistent and correlate with VPN session failures, collect 'show tech-support' and 'show vpn-sessiondb detail anyconnect' output. On virtual platforms (ASAv, FTDv) or during software crypto fallback, this may indicate CPU resource exhaustion—check CPU utilization during the time of drops. Contact Cisco TAC if the counter increments continuously or if VPN sessions are failing to establish.

Syslogs:

None.

----------------------------------------------------------------

cxsc-bad-hdl

Flow terminated due to session tracking mismatch with service module

This counter increments when traffic redirected to a service module for inspection is returned with inconsistent session tracking information. The firewall maintains a session identifier for each flow sent to the service module; if the module returns a packet with a different identifier than previously established for that flow, it indicates the module has lost synchronization with the firewall's connection state. This is a critical error that results in immediate termination of the affected flow to prevent potential security policy bypass. This counter is most commonly associated with the legacy ASA CX (Context Security) module, which provided next-generation firewall and application visibility features and has reached end-of-life. The condition typically occurs when the service module experiences internal errors, memory pressure, or restarts while traffic is actively being inspected.

Recommendation:

Check the operational status and health of any installed service modules using the 'show module' command. Review syslog messages (particularly message 421004) for details about which flows are affected and whether the service module is experiencing errors or instability. If a CX module is installed, note that this hardware is end-of-life and no longer supported; consider uninstalling it with 'sw-module module cxsc uninstall' if it is not actively required. For other service modules experiencing this condition, verify the module is running current software, check for resource exhaustion (CPU, memory) on the module itself, and review the service module's own logs for errors. If the condition persists, the service module may need to be reloaded or the traffic redirection policy temporarily disabled. Contact Cisco TAC if the issue continues after basic troubleshooting, providing output from 'show module', 'show service-policy', and relevant syslogs.

Syslogs:

421004

----------------------------------------------------------------

cxsc-fail-close

Traffic dropped due to unavailable CX module with fail-close policy

Traffic matching a service policy that redirects to the ASA CX (Context-Aware Security) module has been dropped because the module is unavailable and the policy is configured for fail-close behavior. The CX module provides next-generation firewall capabilities including application visibility, identity-based policy enforcement, and advanced threat protection. When the module is down, unresponsive, or in recovery state, the ASA must choose between two failure modes: fail-close (drop traffic to maintain security posture) or fail-open (allow traffic to bypass inspection to maintain availability). This counter increments when fail-close is configured and enforced. Common causes for module unavailability include module software crashes, backplane communication failures, disk or hardware faults, or administrative actions such as module shutdown or recovery operations.

Recommendation:

Check the CX module status with 'show module' and 'show service-policy' commands. If the module shows as Down, Recover, or Unresponsive, investigate the module health using 'show module details' and review system logs for module-related errors. Attempt to recover the module with 'sw-module module cxsc recover' if it is stuck in a failed state. If the module cannot be brought online and traffic must flow, consider temporarily changing the service policy to fail-open mode to allow traffic to bypass inspection, understanding this reduces security visibility. For persistent module failures, check for disk errors, verify backplane connectivity, and contact Cisco TAC for hardware diagnostics. If fail-close drops are expected during planned maintenance, this behavior is by design and no action is needed.

Syslogs:

429001

----------------------------------------------------------------

cxsc-request

Traffic blocked by ASA CX module policy decision

The ASA CX (Context-Aware Security) service module inspected this traffic and determined it should be blocked based on its configured security policy. The CX module performs advanced application-layer inspection, identity-based policy enforcement, and next-generation firewall functions. After analyzing the packet or flow, the module sent an explicit deny action back to the ASA data plane, which dropped the traffic and incremented this counter. This is normal policy enforcement behavior when traffic violates CX security rules—for example, when an application is blocked, a URL category is denied, or user identity-based policy prohibits the connection. The counter reflects successful policy enforcement, not a malfunction.

Recommendation:

Review the CX module logs and alerts to identify which security policy rule triggered the block. Use 'show module' to verify the CX module status and 'show service-policy cxsc' to view redirection statistics. Check syslog message 429002 for details about the specific flow that was dropped, including source and destination addresses. If legitimate traffic is being blocked, adjust the CX security policy accordingly through the CX management interface. Note: The ASA CX module reached end-of-sale and end-of-life status and is no longer supported in current software releases. Organizations using CXSC should plan migration to Firepower Threat Defense (FTD) or ASA with FirePOWER Services for continued next-generation firewall capabilities.

Syslogs:

429002

----------------------------------------------------------------

dtls-hello-close

DTLS ClientHello session validation failure

This counter increments when the firewall receives a DTLS ClientHello message containing a session ID that does not match any existing DTLS session in the session table. This occurs during DTLS session resumption attempts for AnyConnect VPN connections when a client tries to resume a session that has already expired, been cleared, or never existed on the firewall. The firewall closes the UDP connection immediately after processing the ClientHello to conserve resources and prevent potential denial-of-service attacks from invalid session resumption attempts. This is normal behavior when clients attempt to resume stale sessions after a firewall reload, failover, or session timeout. The client will typically fall back to establishing a new DTLS session or continue using the existing TLS connection over TCP.

Recommendation:

This counter incrementing is expected behavior and does not indicate a problem in most cases. Common scenarios include: AnyConnect clients attempting to resume DTLS sessions after the firewall has reloaded or failed over; clients with stale session IDs trying to reconnect after their sessions timed out; or clients that were disconnected and are attempting fast reconnection. If this counter is incrementing frequently during normal operations, verify that DTLS session timeouts are appropriately configured and that clients are successfully establishing new DTLS sessions when resumption fails. Use 'show vpn-sessiondb detail anyconnect' to verify active DTLS tunnels are being established. No action is required unless users report VPN connectivity issues, in which case verify UDP port 443 (or the configured DTLS port) is not being blocked by intermediate devices.

Syslogs:

None.

----------------------------------------------------------------

dynamic-filter

Botnet Traffic Filter dropped traffic matching blacklist or greylist

Traffic was dropped because it matched an entry in the Botnet Traffic Filter (BTF) database with a threat level that exceeds the configured drop threshold. This counter increments when the dynamic-filter drop command is configured and a connection matches either a blacklist entry or a greylist entry (when grey-is-black is enabled) with a threat level within the configured range. The Botnet Traffic Filter compares source and destination IP addresses and DNS lookups against threat intelligence databases (both dynamically updated from Cisco and locally configured static lists). When a match occurs and the threat level meets or exceeds the drop threshold, the connection is blocked and this counter increments. This is the expected behavior when BTF is actively protecting the network from known malicious hosts.

Recommendation:

This counter indicates that Botnet Traffic Filter is working as designed to block malicious traffic. Review the associated syslogs (338005, 338006 for blacklist; 338203, 338204 for greylist) to identify the internal IP addresses communicating with malicious destinations. Use 'show dynamic-filter reports top-malware-sites' to see which malicious sites are being contacted most frequently. Investigate the internal hosts to determine if they are infected with malware. If legitimate traffic is being blocked, verify the threat-level threshold configured with 'dynamic-filter drop' is appropriate for your environment, or add the destination to the dynamic-filter whitelist if it is a known false positive. To view current BTF configuration, use 'show running-config dynamic-filter'. If drops are unexpected and BTF is not intentionally configured, verify that no dynamic-filter commands are present in the configuration.

Syslogs:

338005, 338006, 338203, 338204

----------------------------------------------------------------

fin-timeout

Half-Closed TCP Connection Timeout

A TCP connection was removed because it remained idle in the half-closed state beyond the configured timeout. A connection enters the half-closed state when one side has sent a FIN packet and received the corresponding ACK, but the other side has not yet closed its end of the connection. This is a normal part of graceful TCP connection teardown. The default half-closed timeout is 10 minutes, which prevents connections from consuming resources indefinitely when one endpoint has closed but the other has not. This counter increments when legitimate long-lived half-closed connections exceed the timeout, or when applications do not properly complete the connection teardown sequence in a timely manner.

Recommendation:

Review the connections being timed out using syslog 302014 to determine if they are legitimate long-running sessions or stale connections. If the connections are valid and require more time to complete their teardown (for example, applications that keep one side of the connection open for extended periods), increase the half-closed timeout using the 'timeout half-closed' command. The minimum configurable value is 30 seconds. If the timeouts are occurring on stale connections that should have closed, investigate why the remote endpoints are not completing the TCP teardown sequence properly. In environments with high connection volumes, excessively long half-closed timeouts can lead to resource exhaustion, so balance the timeout value against your connection table capacity. Note that in older software versions, the half-closed timer may not reset when traffic is seen; if you observe this behavior, consider upgrading to a current release.

Syslogs:

302014

----------------------------------------------------------------

flow-missing-snort-info

Flow missing inspection engine metadata

A connection was terminated because it lacks the internal metadata required to communicate with the threat inspection engine. This occurs on Firepower Threat Defense (FTD) when a packet arrives on a flow that should be inspected, but the necessary state information for sending traffic to the inspection engine is missing. The affected flow is torn down and the packet is dropped. ICMP error packets on such flows are allowed to bypass inspection rather than being dropped.

Recommendation:

This counter indicates an internal state inconsistency between the data plane and the inspection engine. Occasional increments may occur during system transitions (such as inspection engine restarts or policy changes). If this counter increments frequently or continuously, verify that the inspection engine is running normally using 'show snort' and check for related syslogs indicating inspection engine failures or communication issues. Collect a troubleshooting bundle and contact Cisco TAC if the problem persists, as this may indicate a software defect or resource exhaustion affecting inspection metadata allocation.

Syslogs:

None directly associated. Related inspection engine issues may generate syslog 850001 or 850002 (Automatic-Application-Bypass events).

----------------------------------------------------------------

flow-reclaimed

Connection reclaimed to make room for new flow

This counter increments when the device has reached its maximum connection limit and removes an existing low-priority connection to accommodate a new incoming connection request. The device maintains a list of 'preemptable' connections that can be sacrificed when resources are exhausted. These are typically short-lived or less critical protocols. The system will only reclaim a connection if the number of preemptable connections exceeds a threshold based on the licensed VPN tunnel count. Connections that are never preempted include: TCP and UDP flows, GRE tunnels, failover protocol connections, ICMP flows when stateful ICMP inspection is enabled, and ESP flows destined to the device itself. All other protocol flows (such as ICMP without stateful inspection, IP-in-IP, SCTP, and other IP protocols) are candidates for reclamation. When a connection is reclaimed, syslog 302021 is generated for ICMP flows.

Recommendation:

Occasional increments are normal and indicate the device is managing connection resources efficiently under load. Rapid or sustained increments suggest the device is operating at or near its connection capacity, which may indicate: (1) the connection limit is too low for the traffic volume—consider increasing licensed connection limits or reviewing 'limit-resource' settings in multi-context mode, (2) an abnormally high volume of non-TCP/UDP traffic (ICMP floods, scanning activity, or protocol anomalies) is consuming connection table entries, or (3) a potential denial-of-service attack is forcing constant connection churn. Review 'show conn count' to verify current utilization, examine 'show asp drop' for other resource-related drops, and correlate with syslog 302021 messages to identify which flows are being torn down. If legitimate traffic is being impacted, enable stateful ICMP inspection ('policy-map global_policy / class inspection_default / inspect icmp') to protect ICMP flows from reclamation, or adjust connection timeouts to age out idle flows more quickly.

Syslogs:

302021

----------------------------------------------------------------

fo-primary-closed

Standby unit removed flow after active unit teardown

The standby unit in a high availability pair received a notification from the active unit that a connection was closed, and removed its local copy of that flow. This is normal behavior in stateful failover configurations where the standby unit maintains synchronized copies of active flows. When the active unit tears down a connection (due to timeout, reset, FIN exchange, or administrative action), it sends a delete message to the standby unit, which then removes its mirrored flow entry and increments this counter. The counter reflects the volume of connection teardowns being replicated from active to standby.

Recommendation:

This counter should increment at a rate roughly proportional to connection teardowns on the active unit. In a healthy stateful failover deployment, expect this counter to track closely with connection teardown activity. If this counter is zero on a standby unit in an active/standby pair with stateful failover enabled, verify that flow replication is functioning correctly using 'show failover' and check for failover link connectivity issues. Unusually high values relative to active unit connection activity may indicate premature flow deletions or failover communication problems. Compare this counter between active and standby units; significant discrepancies warrant investigation of the failover data link and replication health. This is an informational counter and does not indicate packet loss or service impact.

Syslogs:

302014, 302016, 302018

----------------------------------------------------------------

fo-standby

Dropped by standby unit

This counter increments when a packet that would traverse the device (through-the-box traffic) arrives at a unit or security context that is in standby state. Standby units do not maintain connection state for transit traffic; when such a packet arrives and would normally create a new connection, the device immediately drops the packet and removes the connection entry. This behavior prevents the standby unit from accumulating connection state that would require cleanup during a failover event. The counter applies to both Active/Standby failover pairs and to standby contexts in Active/Active failover configurations. Traffic destined to the device itself (to-the-box) for management purposes is not affected by this drop reason.

Recommendation:

This counter should remain at zero on the active unit or active contexts. Incrementing values on the active side indicate a failover state problem—verify failover status with 'show failover' and check for split-brain conditions. On standby units or standby contexts, incrementing counters are normal and expected. If the standby counter grows rapidly, it may indicate that client traffic is being incorrectly routed to the standby unit's IP addresses; verify that routing, load balancers, and clients are directing traffic to the active unit's IP addresses. In Active/Active configurations, ensure traffic is reaching the correct context. Occasional increments during failover transitions are normal as the units exchange roles.

Syslogs:

302014, 302016, 302018

----------------------------------------------------------------

fo_rep_err

Standby flow replication error

The standby unit in a high availability pair failed to replicate a connection from the active unit. This counter increments when the standby receives a state update message but cannot create or update the corresponding connection in its local table. Common causes include: the required network address translation entry has not yet been replicated to the standby (timing issue); a parent connection required for child flows (such as inspection pinholes) is missing on the standby; the interfaces referenced in the update cannot be located; or internal resource contention prevents locking the connection structure. For VPN traffic, this counter may increment steadily during normal operation because IPsec flows can be replicated before the associated IKE security association information arrives—the flows will be re-synchronized once the IKE state is available, so these increments are expected and benign.

Recommendation:

If the appliance is processing VPN traffic, steady increments on the standby unit are normal and require no action—the counter reflects timing differences in replicating IPsec flows versus IKE state. If the appliance is not processing VPN traffic, or if the counter is increasing rapidly (hundreds per minute), this indicates a replication problem. Enable 'debug fover fail' on the standby unit to capture detailed failure information, then contact Cisco TAC with the debug output, the output of 'show failover', and a copy of the running configuration from both units. Check that both units are running compatible software versions and that the failover link has sufficient bandwidth and low latency.

Syslogs:

302014, 302016, 302018

----------------------------------------------------------------

fover-idle-timeout

Standby unit removed stale connection due to missing updates from active unit

This counter increments on the standby unit in a stateful failover pair when a connection is removed because periodic state updates from the active unit have stopped arriving. In stateful failover, the active unit continuously sends connection state updates to the standby unit to keep the connection table synchronized. These updates use unreliable messaging, so if a deletion message is lost or if the active unit removes a connection without notification, the standby unit may retain an orphaned entry. A background timer detects connections that have not received updates within the expected interval and removes them to prevent stale state accumulation. This is a normal cleanup operation that maintains consistency between the failover peers.

Recommendation:

This counter is informational and indicates normal operation of the stateful failover cleanup mechanism. Occasional increments are expected, especially in environments with high connection churn or brief network interruptions on the failover link. If this counter increases rapidly or continuously, verify that the failover link between the active and standby units is stable and not experiencing packet loss. Check 'show failover' to confirm the failover link status is healthy. Persistent high values may indicate failover link congestion or reliability issues that should be investigated. The connections removed by this mechanism would have already been closed on the active unit, so no active traffic is affected.

Syslogs:

None.

----------------------------------------------------------------

geneve-encap-error

Geneve Encapsulation Failed

The device failed to add Geneve tunnel headers to an outbound packet. This occurs when the device attempts to encapsulate traffic for transmission through a Geneve tunnel (including AWS Gateway Load Balancer deployments) but encounters one of two conditions: either the packet buffer lacks sufficient headroom to prepend the Geneve, UDP, IP, and Ethernet headers, or the resulting encapsulated packet would exceed the maximum supported frame size or the configured interface MTU. The counter increments for both standard Geneve peer tunnels and AWS GWLB proxy modes (single-arm and dual-arm). When this error occurs, the packet is dropped and the associated flow may be freed.

Recommendation:

Check the MTU configuration on the VTEP interface and ensure it accommodates the Geneve encapsulation overhead (typically 50-70 bytes depending on IP version and options). For AWS GWLB deployments, verify that the MTU on both the VTEP and VNI interfaces is set appropriately—AWS recommends an MTU of at least 1500 bytes on the VTEP interface to handle encapsulated traffic. If drops persist, examine the inner packet sizes arriving at the device; packets close to the interface MTU will fail encapsulation. Consider enabling Path MTU Discovery on upstream devices or reducing the MSS for TCP connections traversing the tunnel. If the counter increments frequently with small packets, this may indicate a memory or buffer allocation issue—collect a troubleshooting bundle and contact Cisco TAC.

Syslogs:

None.

----------------------------------------------------------------

host-removed

Flows removed by administrative clear operations

Flows were torn down in response to administrative commands that clear host database entries or interface-specific connections. This counter increments when the system removes active connections as part of clearing operations, including the deprecated 'clear local-host' command (which removes all flows associated with specific host IP addresses), interface-specific connection clearing during NAT configuration changes, or security zone cleanup operations. The counter tracks intentional administrative actions rather than error conditions. In clustered deployments, clearing operations affect flows on the local unit; earlier software versions had a defect where clearing a single host could inadvertently remove cluster stub flows across all units.

Recommendation:

This is an informational counter that confirms administrative clear operations completed successfully. No action is required unless the counter increments unexpectedly without corresponding administrative commands. If you observe unexpected increments, verify whether automated scripts or management platforms are issuing clear commands. Review the associated teardown syslogs (302xxx series for connection teardowns, 305xxx for translation teardowns, 609002 for host removal) to identify which specific hosts or interfaces were affected. In clustered environments running software earlier than 9.6(4), 9.8(3), or 9.9(1), be aware that 'clear local-host' commands may have unintentionally cleared stub flows across the entire cluster; upgrade to a fixed version if this behavior is observed.

Syslogs:

302014, 302016, 302018, 302021, 305010, 305012, 609002

----------------------------------------------------------------

ifc-addr-chg

IKE flows cleared due to tunnel source interface address change

This counter increments when the system removes IKE (Internet Key Exchange) flows that have become stale due to an IP address change or removal on an interface configured as a tunnel source for Virtual Tunnel Interfaces (VTI). When a tunnel source interface experiences an address change—such as during VRF reassignment, IP address reconfiguration, or interface address removal—any existing IKE flows bound to the old interface configuration are no longer valid. The system proactively clears these flows to prevent them from referencing incorrect outbound interface information. This cleanup ensures that subsequent tunnel establishment uses the current interface configuration. The counter typically increments during administrative changes to site-to-site VPN configurations, particularly when modifying VRF membership or IP addressing on interfaces that serve as tunnel sources for static VTI (SVTI) or dynamic VTI (DVTI) tunnels.

Recommendation:

No action is required. This counter reflects normal system behavior during tunnel source interface reconfiguration. The cleared flows will be automatically re-established using the updated interface configuration when tunnel traffic resumes. If you observe this counter incrementing without corresponding configuration changes, verify that the tunnel source interface is stable (check for interface flapping, DHCP address changes, or routing instability). After making intentional changes to tunnel source interface addressing or VRF membership, confirm that VPN tunnels re-establish successfully by checking 'show crypto ikev2 sa' or 'show crypto ipsec sa'. If tunnels fail to re-establish after configuration changes, review the tunnel source interface configuration and ensure the interface has a valid IP address in the correct VRF context.

Syslogs:

None

----------------------------------------------------------------

ifc-vrf-chg

Flows terminated due to interface VRF assignment change

This counter increments when active connections are terminated because the interface they traverse has been moved from one Virtual Routing and Forwarding (VRF) instance to another. When an administrator changes the VRF assignment on an interface (for example, using the 'vrf forwarding' command), all existing flows associated with that interface are immediately cleared. This ensures routing consistency, prevents traffic from being forwarded using stale routing information, and notifies the inspection engine to clear its session state. The counter applies to both adding a VRF to an interface previously in the global routing table and moving an interface between different VRF instances. This behavior is expected during VRF reconfiguration and affects all connection types (TCP, UDP, ICMP) that were using the interface.

Recommendation:

No action is required. This is expected behavior during VRF reconfiguration. Existing connections through the affected interface will be dropped and must be re-established by the endpoints. To minimize disruption: plan VRF changes during maintenance windows, notify users that active sessions will be interrupted, and verify that routing and security policies are correctly configured for the new VRF before making the change. If you observe this counter incrementing without any recent VRF configuration changes, review the configuration history and check for automation or orchestration systems that may be modifying interface VRF assignments.

Syslogs:

None.

----------------------------------------------------------------

ifc-zn-chg

Interface zone membership changed

Existing connections were terminated because the interface zone membership was modified. This occurs when an administrator adds or removes an interface from a security zone using the 'zone-member' command, deletes a zone with 'no zone', or clears zone configuration with 'clear config zone'. Security zones group interfaces for zone-based firewall policies and ECMP routing; when zone membership changes, all active flows on the affected interface are torn down to ensure traffic is re-evaluated under the new zone policy. This is expected behavior during configuration changes and does not indicate a problem.

Recommendation:

No action required. This counter increments during normal zone configuration changes. If you observe unexpected increments when no zone configuration changes were made, verify that no automated scripts or management systems are modifying zone membership. The associated syslogs (302014, 302016, 302018, 302021, 302304) provide details about which connections were terminated, including source/destination addresses, duration, and byte counts. After completing zone configuration changes, existing clients will automatically re-establish connections, which will then be subject to the security policies of the new zone assignment.

Syslogs:

302014, 302016, 302018, 302021, 302304

----------------------------------------------------------------

ike-pkt-with-bad-spi

IKEv2 packet dropped due to invalid or expired SPI in cluster

This counter increments when an IKEv2 packet is dropped because its Security Parameter Index (SPI) fails validation in a clustered deployment running Distributed VPN mode. The cluster embeds a cryptographic timestamp and member identifier into each IKEv2 SPI to ensure packets are directed to the correct cluster member and to prevent denial-of-service attacks. The drop occurs when either the SPI timestamp has exceeded the age threshold (expired) or the cryptographic validation fails (corrupted or tampered). Common triggers include: clock skew between cluster members when NTP is not synchronized, NAT devices in the path that delay packet delivery beyond the SPI validity window, legitimate SPI expiration during slow or interrupted IKEv2 negotiations, or actual attack attempts using replayed or forged SPIs. This is a datapath security check specific to clustered IKEv2 deployments and does not occur on standalone units.

Recommendation:

Review syslog message 753001 to identify the source IP address and specific error reason (expired vs. corrupted). If drops are infrequent and scattered across different peers, this is typically benign—the remote peer will retransmit and establish the tunnel successfully. If drops persist for specific peers: verify all cluster members have synchronized clocks using NTP (check 'show clock' and 'show ntp status' on each unit), check for NAT devices or high-latency paths between the peer and cluster that might delay IKEv2 packets beyond the validity window, and confirm the remote peer is not experiencing its own clock drift. If drops occur during cluster membership changes or immediately after a unit joins, allow time for cluster synchronization to stabilize. Contact TAC if drops continue after verifying time synchronization, as this may indicate network issues, cluster configuration problems, or actual attack traffic.

Syslogs:

753001

----------------------------------------------------------------

inspect-fail

Protocol inspection setup failure

The device failed to enable hardware-accelerated protocol inspection for a new connection. This counter increments in two scenarios: (1) Memory allocation failure when setting up inspection resources during connection establishment, or (2) For ICMP error messages, the device could not locate the original connection referenced in the embedded packet payload. When ICMP error inspection is enabled, the device must find the flow that triggered the error message in order to properly translate addresses in the embedded packet; if that original connection no longer exists or cannot be found, the ICMP error packet is dropped. This typically occurs during high connection rates, memory pressure, or when ICMP errors arrive for connections that have already timed out.

Recommendation:

Check system memory usage with 'show memory' and 'show blocks'. If memory is low, investigate what is consuming resources. For ICMP error drops, verify syslog 313004 to confirm the specific cause. If ICMP errors are being dropped because the original connection has closed, this is normal behavior and may occur during network path changes or when intermediate routers send errors for short-lived connections. If the drops correlate with connection setup failures, check for memory exhaustion or resource limits. If ICMP error drops are excessive and appear to be from an attack (spoofed ICMP errors with no matching connection), consider using ACLs to filter untrusted ICMP traffic. Contact TAC if drops occur without memory pressure or if they impact legitimate traffic.

Syslogs:

313004 (ICMP error message with no matching session)

----------------------------------------------------------------

inspect-scansafe-server-not-reachable

Cloud Web Security server unavailable or not configured

This counter increments when HTTP or HTTPS traffic matches a Cloud Web Security (formerly ScanSafe) inspection policy, but the traffic cannot be redirected to the cloud proxy because either no server is configured, all configured servers are unreachable, or the cloud service is marked as unavailable. The device performs periodic health checks to both primary and backup servers; if both fail their health checks, the cloud is marked down and this counter increments for subsequent matching traffic. The behavior when the cloud is unavailable depends on the fail-open or fail-close setting in the inspection policy: fail-close drops the traffic (this counter), while fail-open permits it without inspection.

Recommendation:

Verify Cloud Web Security configuration with 'show scansafe server' to check server reachability status, DNS resolution (if using FQDNs), and active server selection. If servers are configured but unreachable, check network connectivity to the cloud proxy on the configured HTTP (typically 8080) or HTTPS (typically 8443) ports, verify routing and NAT, and confirm the cloud service is operational. If no servers are configured, complete the Cloud Web Security setup under 'scansafe general-options' including server IP/FQDN, port, and license key. Review the inspection policy's fail-open or fail-close behavior: if fail-close is configured, traffic will be dropped when the cloud is unavailable (expected behavior); if fail-open is configured but traffic is still being dropped, investigate why the cloud status is not being updated correctly. Syslog 775004 accompanies this drop when the primary server becomes unreachable.

Syslogs:

775004

----------------------------------------------------------------

invalid-geneve-segment-id

Invalid Geneve Segment-ID

The security appliance dropped a Geneve-encapsulated packet because the Virtual Network Identifier (segment-id) in the packet header does not match any configured VNI interface, or because the packet lacks the required segment-id metadata for encapsulation. This counter increments in two scenarios: (1) On ingress, when a Geneve packet arrives on a VTEP interface but the segment-id in the Geneve header cannot be matched to a local VNI interface in the same security context. (2) On egress, when the appliance attempts to encapsulate and send a packet through a VNI interface but the outbound segment-id is missing or invalid in the packet's internal metadata. This drop is common in Geneve overlay networks including standard NVE deployments and AWS Gateway Load Balancer (GWLB) proxy configurations (both single-arm and dual-arm modes). In AWS proxy single-arm mode, the segment-id from the incoming packet is reused for the return path; mismatches here indicate configuration or routing issues.

Recommendation:

For ingress drops: Verify that the segment-id in the arriving Geneve packets matches a segment-id configured on a VNI interface using 'show interface vni' and 'show nve'. Check that the VNI interface is in the same security context as the receiving VTEP interface. Review the remote peer's Geneve configuration to ensure it is sending the correct segment-id. For egress drops: Confirm that the VNI interface has a segment-id configured (required for non-AWS-proxy deployments). For AWS GWLB deployments, verify that 'proxy single-arm' or 'proxy dual-arm' is correctly configured on the VNI interface. Check for routing or policy issues that might cause packets to be forwarded to a VNI interface without proper flow state. If drops persist without configuration mismatches, collect 'show asp drop' output, packet captures on the VTEP interface, and contact Cisco TAC—internal metadata corruption has been observed in rare corner cases.

Syslogs:

778010

----------------------------------------------------------------

invalid-map-address-port

Invalid MAP Address or Port Combination

A packet from a device within a MAP-T (Mapping of Address and Port with Translation) domain failed validation because either the Port Set Identifier encoded in the IPv6 source address is inconsistent with the address structure, or the source port number falls outside the port range allocated to that device. MAP-T is a stateless IPv4-to-IPv6 translation technology used by service providers to share IPv4 addresses among multiple customers. Each customer device is assigned a specific IPv4 address and a subset of port numbers, identified by a Port Set ID. The firewall validates that outbound IPv6 packets from MAP customer edge devices correctly encode their assigned PSID in both the IPv6 address and use only their allocated port range. This drop indicates either a misconfigured MAP customer edge device that is using an incorrect address encoding, or a device attempting to use port numbers outside its allocation—potentially due to configuration mismatch between the customer edge and border relay, or a compromised device deliberately violating port allocation rules.

Recommendation:

Review the MAP domain configuration on both the border relay (this device) and the customer edge device to ensure the Basic Mapping Rule parameters match: IPv6 prefix, IPv4 prefix, sharing ratio, and starting port must be identical. Verify the customer edge device is correctly calculating its Port Set ID and encoding it into outbound IPv6 addresses per RFC 7599. Check the source IPv6 address and port in syslog messages 305019 (inconsistent PSID encoding) or 305020 (port out of range) to identify the misconfigured device. If the configuration is correct on both sides, investigate whether the customer edge device has been compromised or is running faulty software that generates non-compliant packets. This drop is expected and correct behavior when enforcing MAP-T port allocation policies; it prevents address spoofing and unauthorized port usage within the MAP domain.

Syslogs:

305019, 305020

----------------------------------------------------------------

invalid-peer-nve

Invalid Peer NVE

The device dropped a packet during VXLAN or Geneve tunnel encapsulation because it could not retrieve the statically configured remote peer information. This occurs when the device attempts to encapsulate inner traffic for transmission to a remote tunnel endpoint, but the static peer configuration is missing, incomplete, or the peer information cannot be resolved. The counter increments when a static peer IP address is configured on the Network Virtualization Endpoint interface but the peer details (IP address and MAC address) cannot be retrieved from the configuration. This typically happens during initial configuration deployment, after configuration changes that affect the tunnel peer, or when routing to the peer is unavailable.

Recommendation:

Verify the NVE configuration includes a valid static peer IP address using 'show nve 1' and 'show run nve'. Confirm that a route exists to reach the configured peer IP address using 'show route'. If the peer IP is not directly connected, ensure a static or dynamic route is configured that provides reachability to the remote tunnel endpoint. Check that the source interface for the NVE is configured and operational. If the counter increments during configuration deployment, verify the peer IP address is correct and reachable before applying the NVE peer configuration. For VXLAN configurations, ensure the peer is configured using either 'peer ip', 'peer-group', or 'default-mcast-group' but not a mix of these mutually exclusive options. If the issue persists after verifying configuration and routing, contact Cisco TAC with the output of 'show nve 1 detail', 'show route', and 'show asp drop' for further analysis.

Syslogs:

None directly associated with this drop counter. Related syslog %ASA-6-778007 may appear for invalid peer detection on received packets.

----------------------------------------------------------------

invalid-vxlan-segment-id

Invalid VXLAN segment-id

The device dropped a packet because it could not determine a valid VXLAN Network Identifier (VNI) segment ID for encapsulation. This occurs when traffic is being sent out a VNI interface but the segment ID is missing, invalid, or cannot be resolved. Common scenarios include: (1) A VNI interface was brought up without a configured segment-id, (2) Internal packet metadata is missing when attempting VXLAN encapsulation (often seen with cluster control link redirected packets or certain tunnel passenger flows), (3) For tag-switching configurations, the ingress segment ID could not be translated to a valid egress segment ID, or (4) The segment ID lookup failed to find a corresponding VNI interface. This counter may also increment if a packet reaches the VNI transmit path before the interface is fully configured.

Recommendation:

Check the VNI interface configuration and verify that a segment-id is configured on all VNI interfaces that are expected to carry traffic. Use 'show interface' to confirm VNI interfaces have valid segment IDs assigned. If using VXLAN tag-switching (segment-to-segment translation), verify the STS table mappings with 'show vxlan tag-switching' and ensure ingress segment IDs have corresponding egress mappings. If drops occur during configuration changes, they may be transient—monitor whether they continue after the configuration stabilizes. For persistent drops, collect 'show asp drop' output, interface configurations, and VXLAN peer information. If drops correlate with cluster or high-availability events, check for proper CCL (cluster control link) configuration. In most cases, ensuring all VNI interfaces have segment-id configured before assigning a nameif will prevent this condition.

Syslogs:

778002, 778003

----------------------------------------------------------------

ips-conn-timeout

IPS Connection Idle Timeout

A TCP connection was closed because it exceeded the configured idle timeout while being inspected by the threat defense engine with performance optimization enabled. This applies to established connections (not embryonic sessions) that use a lightweight state tracking mechanism for improved throughput. The optimization is typically active when interfaces are configured as inline pairs or when SSL/TLS decryption policies are applied. The connection remained idle without any traffic for longer than the configured TCP idle timeout period.

Recommendation:

This is normal behavior for idle connections. If legitimate long-lived connections are being prematurely closed, increase the TCP idle timeout using the 'timeout conn' command or apply a longer timeout via service policy for the affected traffic class. The default TCP idle timeout is 1 hour. Review connection patterns to determine if applications maintain persistent connections without keepalive traffic. For inline interface deployments, verify that the timeout value accommodates expected application behavior. If connections are actively passing traffic but still timing out, this may indicate a software defect—collect 'show conn detail' output and contact Cisco TAC.

Syslogs:

302014

----------------------------------------------------------------

ips-fail-close

IPS fail-close

Packets are dropped because they are subject to intrusion prevention inspection, but the IPS module is unavailable and fail-close mode is configured. This counter increments when one of three conditions exists: the IPS card or module is not operational, the IPS license is not active, or no virtual sensor has been assigned to the traffic's security context. In fail-close mode, the device prioritizes security by dropping traffic when inspection cannot be performed. This behavior is expected and protects the network when the IPS subsystem cannot analyze traffic. The counter typically appears on ASA platforms with hardware IPS modules (AIP-SSM, SSM) configured for inline inspection.

Recommendation:

Verify the operational status of the IPS module using 'show module' and confirm the module state is 'Up'. Check that a valid IPS license is installed with 'show activation-key' or 'show version'. For multi-context deployments, ensure each context has a virtual sensor allocated using 'show ips' and verify the sensor name matches the configuration on the IPS module. Review syslog 420001 messages to identify which traffic is being dropped and whether the drops correlate with module state changes or configuration updates. If fail-close behavior is too restrictive during maintenance windows or module failures, consider changing to fail-open mode, which allows traffic to bypass inspection when the IPS is unavailable. If the module remains down, troubleshoot module communication using 'session 1' to access the module console, or contact TAC if hardware or licensing issues persist.

Syslogs:

420001, 420008

----------------------------------------------------------------

ips-license-disabled-fail-close

IPS Module License Disabled (Fail-Close)

Traffic was dropped because the IPS module license is disabled and the service policy is configured for fail-close behavior. This counter applies to ASA 5500 series platforms with an AIP SSM (Advanced Inspection and Prevention Security Services Module) hardware card. When fail-close mode is configured, the firewall drops all traffic that would normally be sent to the IPS module for inspection if the module is unlicensed. This is the secure default that prevents uninspected traffic from passing through when IPS inspection cannot be performed. The alternative fail-open mode would allow traffic to bypass IPS inspection when the license is unavailable.

Recommendation:

Verify the IPS module license status with 'show activation-key' and check for the IPS module license feature. If IPS inspection is required, apply a valid activation key that includes the IPS module license using the 'activation-key' command. If IPS inspection is not needed, either remove the 'ips' command from the service policy or change the fail-close configuration to fail-open mode (though this reduces security posture). Note that this counter is specific to legacy ASA 5500 series hardware with physical AIP SSM modules; modern FTD platforms use integrated Snort inspection and have different licensing models.

Syslogs:

420008

----------------------------------------------------------------

ips-request

Packet dropped by IPS inspection policy

The intrusion prevention system (IPS) or Snort inspection engine requested that a packet or flow be dropped based on a matched security policy rule. This occurs when traffic matches an IPS signature configured with a drop or block action, when application control blocks an application, or when URL filtering denies access to a category. The drop applies to inline IPS deployments where the inspection engine is in the forwarding path and can enforce blocking actions. Affected traffic includes TCP connections (terminated with RST), UDP sessions, ICMP messages, and other IP protocols. Under heavy inspection load, legitimate traffic such as DNS replies or ICMP echo responses may occasionally be dropped if the IPS engine cannot process packets quickly enough before flow state expires.

Recommendation:

Review syslog message 420002, which identifies the specific protocol, source and destination interfaces, IP addresses, and port numbers of the dropped traffic. Check the IPS or Snort event logs on the inspection module to identify which signature or policy rule triggered the drop, and verify whether the block action is intended. If legitimate traffic is being blocked, adjust the IPS policy to exempt the traffic, tune or disable the triggering signature, or create an exception rule. If drops occur during high traffic load and affect time-sensitive protocols like DNS or ICMP, consider reducing the inspection load by exempting trusted traffic from IPS inspection, or evaluate whether the hardware can handle the inspection throughput. For VPN traffic drops, verify that encrypted traffic is properly exempted from inline inspection or that decryption policies are correctly configured.

Syslogs:

420002

----------------------------------------------------------------

ips-syn-timeout

IPS SYN Timeout

A TCP connection that had not completed the three-way handshake (embryonic state) was closed because it exceeded the configured embryonic connection timeout. This counter applies specifically to connections on interfaces configured in inline mode or inline-pair mode, where traffic is inspected by the intrusion prevention system using lightweight state tracking for performance optimization. In this mode, full TCP normalization is bypassed and the system maintains minimal connection state, tracking only basic TCP handshake progress. When a SYN is received but the handshake does not complete within the embryonic timeout period (default 30 seconds), the connection is torn down and this counter increments. This is normal behavior for incomplete or abandoned connection attempts, including port scans, failed connection attempts, or clients that do not complete the handshake in time.

Recommendation:

This counter typically indicates legitimate incomplete connections and is not a cause for concern in most environments. Common causes include network latency, client timeouts, port scanning activity, or applications that initiate connections slowly. If you observe a high rate of these drops for legitimate traffic that requires more time to establish connections (such as connections over high-latency links or from slow-responding clients), you can increase the embryonic connection timeout using the 'set connection timeout embryonic' command in a service policy applied to the affected traffic class. Note that on inline and inline-pair interfaces, the ability to configure per-client embryonic connection limits and custom timeout values may be limited compared to routed interfaces, as these interfaces use optimized inspection paths with minimal connection tracking. Review syslog message 302014 to identify which connections are timing out. If drops correlate with known port scanning or attack activity, the current timeout is appropriate and no action is needed.

Syslogs:

302014

----------------------------------------------------------------

ipsec-detunnel-fail

IPsec detunnel processing failed

This counter increments when a packet has been successfully decrypted by IPsec but the system fails to complete the detunnel processing required to forward the clear-text traffic. After IPsec decryption, the device must validate the tunnel context and apply any configured VPN filters (per-user or group-policy ACLs) to the decrypted packet. This counter fires when that validation fails. Common causes include: the tunnel Security Association has been deleted or is being rekeyed while packets are still arriving; the VPN context has expired or become invalid; internal resource contention preventing access to tunnel state; or the decrypted traffic is denied by a configured VPN filter ACL. Unlike drops that occur during decryption itself, this counter indicates the packet was successfully decrypted but could not be processed as clear-text traffic.

Recommendation:

Check the status of the affected IPsec tunnel with 'show crypto ipsec sa' to verify the tunnel is fully established and not in a rekey or teardown state. If VPN filters are configured (via 'vpn-filter' under group-policy or username), verify the ACL permits the decrypted traffic using 'show access-list'. Review 'show asp drop' for related counters that may indicate the specific failure: look for 'acl-drop' (VPN filter denied the traffic), 'vpn-lock-err' (resource contention), or 'vpn-expired' (stale tunnel context). If drops occur during tunnel rekey operations, this may indicate a known issue (CSCwc95290) where the VPN context is not properly updated during SA transitions—verify you are running a fixed software version. For persistent issues, collect 'show tech-support' and 'show asp drop' output and contact Cisco TAC.

Syslogs:

None

----------------------------------------------------------------

ipsec-selector-failure

IPsec VPN traffic selector policy mismatch

This counter increments when the device receives and decrypts an IPsec packet, but the inner (decapsulated) packet does not match the traffic selectors negotiated for that tunnel. Traffic selectors define which packets are permitted through the tunnel based on source and destination addresses, ports, and protocol. The device validates each decrypted packet's source address, destination address, source port, destination port, and protocol against the policy configured in the crypto map ACL. When any of these attributes fall outside the negotiated ranges, the packet is dropped and this counter increments. This typically indicates a configuration mismatch between the local device and the remote VPN peer, where the remote peer is encrypting and sending traffic that was not included in the tunnel negotiation. The mismatch can occur with site-to-site VPN tunnels, Virtual Tunnel Interfaces (VTI), or remote access VPN configurations.

Recommendation:

Check syslog message 402116, which provides detailed information about the mismatch including the received packet's attributes and the expected policy ranges. Compare the crypto map ACL configuration on both VPN peers to ensure they mirror each other—the local device's 'interesting traffic' definition must match what the remote peer considers interesting traffic. Verify that both peers have negotiated the same traffic selectors during IKE Phase 2 (IPsec SA establishment) by examining the output of 'show crypto ipsec sa detail'. If the remote peer is a third-party device, confirm that its VPN policy configuration aligns with the local crypto ACL. If this counter increments persistently with traffic from unexpected source addresses or protocols, investigate whether the remote peer has been compromised or misconfigured to send unauthorized traffic through the tunnel. For VTI configurations, ensure that routing and ACL configurations are consistent. Low, occasional increments may be benign (such as during configuration changes or tunnel renegotiation), but sustained or high-rate increments indicate a configuration problem that will cause traffic loss.

Syslogs:

402116

----------------------------------------------------------------

ipsec-spoof-detect

Cleartext packet matched encrypted tunnel policy

A packet was received in cleartext (unencrypted) that matched the security policy of an established tunnel requiring encryption. The device expected this traffic to arrive encrypted through the tunnel but instead received it as a plain IP packet. This security check prevents spoofing attacks where an attacker sends cleartext packets that appear to originate from inside an encrypted tunnel. Common legitimate causes include: routing protocol packets (such as OSPFv3 hellos) sent to link-local addresses after software upgrades or interface state changes; DNS queries re-injected by security features like Umbrella integration; multicast traffic on Virtual Tunnel Interfaces during failover or tunnel flapping; and mismatched encryption policies between peers where one side expects encryption but the other sends cleartext.

Recommendation:

Check syslog message 402117 to identify the protocol, source, and destination of the dropped traffic. If the traffic is routing protocol control packets (OSPF, EIGRP) on link-local or multicast addresses, verify that both tunnel endpoints have matching encryption policies and that interface configurations are complete after any recent changes. For site-to-site VPN tunnels, confirm that both peers have identical crypto ACLs defining which traffic should be encrypted. If drops occur after a software upgrade, particularly affecting OSPFv3, check that routing protocol sockets are properly initialized (shut/no-shut the interface may resolve). For DNS or other application traffic, verify that security features are not re-injecting packets without proper bypass flags. If drops persist during normal operation with correctly configured matching policies on both peers, contact Cisco TAC as this may indicate an attempted spoofing attack or a software defect.

Syslogs:

402117

----------------------------------------------------------------

loopback

Traffic entering and exiting same interface without required configuration

This drop occurs when traffic attempts to enter and exit through the same physical interface—commonly called hairpin or U-turn traffic—but the required configuration is not present. This traffic pattern is typical in VPN hub-and-spoke topologies where remote sites communicate through a central hub, hairpin NAT scenarios where internal hosts access internal servers via their public addresses, and cloud load-balancer integrations such as AWS Gateway Load Balancer. By default, the firewall blocks same-interface traffic as a security measure. The counter increments when a connection is denied because it would loop back out the ingress interface without the explicit permit configuration.

Recommendation:

To allow traffic to enter and exit the same interface, configure 'same-security-traffic permit intra-interface' in global configuration mode. This is required for VPN hub-and-spoke deployments where spoke-to-spoke traffic transits the hub, for hairpin NAT where users access internal resources via external addresses, and for certain cloud integrations. Verify the traffic pattern is legitimate before enabling this—unexpected same-interface flows may indicate routing misconfigurations, asymmetric routing, or network loops. If drops persist after configuration, check that NAT rules and routing are correctly directing return traffic, and verify security zones or interface security levels are not blocking the flow for other reasons.

Syslogs:

None

----------------------------------------------------------------

max-retries-of-retransmission-exceeded

Maximum Retries of Retransmission Exceeded

The device terminated a connection because it exhausted all retransmission attempts for unacknowledged TCP data without receiving any response from the remote peer. This counter increments when the device is operating in TCP proxy mode and the internal TCP stack determines that the connection is no longer viable after repeated retransmission timeouts. TCP proxy mode is activated for certain application inspections (such as IM, H323, DCERPC, SUNRPC, CTIQBE, RTSP, SIP, Skinny) and for SSL/TLS decryption operations. The device calculates a maximum retransmission time based on the smoothed round-trip time (typically between 7 and 15 minutes for established connections), and if no acknowledgment is received within this window despite exponential backoff retries, the connection is torn down and reset packets are sent to both endpoints.

Recommendation:

This counter typically indicates network connectivity problems, unresponsive remote hosts, or asymmetric routing that prevents acknowledgments from reaching the device. First, verify that the remote endpoint is reachable and responding to traffic. Check for packet loss, high latency, or routing issues between the device and the destination. Review the corresponding syslog message 302014 to identify which connections are timing out and the specific endpoints involved. If the counter increments frequently for connections to a specific server or subnet, investigate that target's network path and health. For SSL/TLS decryption scenarios, ensure that decrypted server connections are not being blocked or rate-limited. If the issue affects only certain application inspections, consider whether the inspection policy is appropriate for the traffic type. In environments with legitimate high-latency or lossy links, this behavior may be expected; however, persistent increments suggest an underlying connectivity issue that should be resolved.

Syslogs:

302014

----------------------------------------------------------------

mcast-entry-removed

Multicast entry removed

A packet arrived that matched an existing multicast flow, but the corresponding forwarding entry in the Multicast Forwarding Information Base (MFIB) has been deleted. This occurs when multicast routing state changes while active flows exist. Common triggers include disabling multicast routing globally or on an interface, clearing multicast configuration, re-enabling multicast after flows were established, or changes to tunnel interfaces (such as VTI zone reassignments or interface state changes). The firewall removes the stale flow and drops the packet as part of normal cleanup. Subsequent packets for the same multicast group will be re-evaluated against the current multicast routing state.

Recommendation:

This counter typically increments during configuration changes, failover events, or administrative actions affecting multicast routing. Brief increments during these events are expected and benign. If the counter increases continuously during stable operation, verify that multicast routing is enabled on the appropriate interfaces and that MFIB entries are being correctly maintained. Use 'show mfib' and 'show pim topology' to confirm multicast forwarding state matches your configuration. For persistent issues with VTI tunnels, verify interface zone assignments and PIM neighbor adjacencies. If multicast traffic is not flowing as expected after configuration changes, allow time for routing protocols to reconverge and flows to be re-established.

Syslogs:

None

----------------------------------------------------------------

mcast-intrf-removed

Multicast output interface removed from forwarding entry

The firewall removed one or more output interfaces from an active multicast forwarding entry and tore down the associated data plane flows. This occurs during normal multicast routing operations when downstream receivers leave a multicast group, when PIM prune messages are received from neighboring routers, when interfaces are administratively shut down or PIM is disabled on them, or when routing topology changes cause the Reverse Path Forwarding interface to shift. Each multicast stream maintains separate forwarding state for each output interface; when the control plane updates the Multicast Forwarding Information Base to remove an interface, the data plane synchronizes by freeing the corresponding flow and incrementing this counter. The counter may increment once per interface removed, or once when all interfaces are removed and the entire multicast entry is deleted.

Recommendation:

No action required. This counter reflects normal multicast state maintenance as group membership and PIM topology change. If the counter increments unexpectedly, verify that IGMP group membership is stable on downstream interfaces, check for unexpected PIM prune messages using 'debug pim', and confirm that no interfaces are flapping or being reconfigured. In environments with frequent IGMP joins and leaves (such as IPTV or video conferencing), moderate counter growth is expected. If multicast traffic is not being forwarded as expected, use 'show mroute', 'show igmp groups', and 'show pim topology' to verify that the correct output interfaces are present in the forwarding entries.

Syslogs:

None

----------------------------------------------------------------

nat-failed

NAT Translation Failed

The device was unable to create a Network Address Translation (NAT) entry for a connection. This occurs when the system cannot allocate the resources needed to translate IP addresses or ports for a flow. Common causes include: no matching NAT policy exists for the traffic (no rule covers the source/destination combination); the NAT or PAT pool has exhausted all available addresses or ports; overlapping NAT rules with conflicting address ranges prevent translation allocation; memory exhaustion prevents creating new translation entries; or in clustered deployments, interface PAT configuration issues cause translation failures on data units while the control unit works normally. The counter increments once per dropped connection attempt.

Recommendation:

First, verify NAT policy coverage by checking that a NAT rule matches the dropped traffic's source and destination using the packet-tracer command. Review the output of 'show nat' to confirm rule hit counts and verify the expected rule is being matched. If using dynamic NAT or PAT, check for pool exhaustion with 'show nat pool' and 'show xlate count' - if pools are exhausted, either expand the pool size, reduce translation timeouts to free entries faster, or investigate why translations are not timing out properly (check for stale entries with 'show xlate'). For clustered deployments experiencing this drop on data units only, verify that interface PAT rules are correctly configured and that the cluster is operating in the expected mode. If you see syslog 305006 with 'portmap translation creation failed', check for overlapping NAT rules where multiple rules use the same or overlapping global IP ranges - consolidate or separate the address ranges to eliminate conflicts. If memory is low (check 'show memory'), this may prevent translation creation. Contact Cisco TAC if drops persist after verifying NAT policy coverage and pool availability, especially if accompanied by syslogs 305005, 305006, or 210007.

Syslogs:

305005, 305006, 305009, 305010, 305011, 305012, 210007, 202010, 305021

----------------------------------------------------------------

nat-rpf-failed

NAT reverse path verification failed

The firewall dropped a connection attempt because the forward and reverse traffic paths would use different NAT policies. This reverse path forwarding check ensures that both directions of a connection use the same translation rule. The most common cause is attempting to connect to a host using its real (untranslated) address when you should be using the mapped (translated) address. For example, if a server on the inside network at 10.1.1.10 is translated to 203.0.113.50 for outside access, clients on other interfaces must connect to 203.0.113.50, not 10.1.1.10. Connecting directly to the real address from a different interface fails this check because the firewall cannot find a matching reverse translation rule. This counter also increments when twice-NAT or manual NAT rules create asymmetric translations where the forward path uses one rule but the expected reverse path would require a different rule that does not exist.

Recommendation:

Check the source and destination addresses in syslog 305005 or 305013 to identify which connection is being dropped. Verify that clients are connecting to the mapped address, not the real address. If the real address must be used, create a bidirectional NAT rule or add a matching reverse translation rule. Use 'packet-tracer' to simulate the connection and see which NAT rule is matched in each direction. If the forward and reverse paths show different NAT rules (or no rule in one direction), you have asymmetric NAT. For legitimate asymmetric scenarios, configure explicit NAT rules for both directions. If this counter increments unexpectedly after an upgrade or configuration change, review your NAT policy for unintended asymmetry. In most cases, this drop is working as designed to prevent routing inconsistencies.

Syslogs:

305005, 305013

----------------------------------------------------------------

nat64/46-conversion-fail

NAT64 or NAT46 incomplete address translation

This counter increments when a connection requires translation between IPv4 and IPv6 address families (NAT64 or NAT46), but after the translation process completes, the resulting connection still contains a mix of IPv4 and IPv6 addresses. Valid translated connections must have both the source and destination addresses in the same IP version—either both IPv4 or both IPv6. This drop indicates that the translation was incomplete or incorrectly configured, leaving one address translated while the other remained in its original IP version. Common causes include incomplete NAT rule configuration, missing or incorrect prefix mappings in NAT64/NAT46 policies, interface-based NAT misconfigurations, or conflicts between multiple NAT rules that prevent proper address family conversion for both endpoints of the connection.

Recommendation:

Review your NAT64 or NAT46 configuration to ensure complete translation rules are in place. Verify that both source and destination translation policies are correctly configured with appropriate IPv6 prefix mappings (typically /96 or shorter for NAT64, /64 or longer for NAT46 static mappings). Check that interface-based NAT rules include proper address family conversion settings. Use 'show xlate' to verify active translations and 'show nat detail' to review NAT rule ordering and matching criteria. If using static NAT with NAT64/NAT46, ensure the mapped addresses use correct prefix lengths and that net-to-net mapping is enabled where required. For persistent issues, enable NAT debugging with 'debug nat' to trace which NAT rules are matching and where the translation is failing. If the problem occurs with VPN traffic, verify that NAT exemption rules are not interfering with the address family translation.

Syslogs:

None.

----------------------------------------------------------------

need-ike

Need to start IKE negotiation

This counter will increment when the appliance receives a packet which requires encryption but has no established IPSec security association. This is generally a normal condition for LAN-to-LAN IPSec configurations. This indication will cause the appliance to begin ISAKMP negotiations with the destination peer.

Recommendation:

If you have configured IPSec LAN-to-LAN on your appliance, this indication is normal and does not indicate a problem. However, if this counter increments rapidly it may indicate a crypto configuration error or network error preventing the ISAKMP negotiation from completing. Verify that you can communicate with the destination peer and verify your crypto configuration via the 'show running-config' command.

Syslogs:

None

----------------------------------------------------------------

no-adjacency

No valid adjacency

This counter increments when a packet arrives on an established connection, but the device can no longer determine the correct next-hop MAC address for forwarding. The flow's cached forwarding information has become invalid, typically because the routing table has changed since the connection was created. The device performs a fresh route lookup, but either the route no longer exists, the next-hop is unreachable, or the Layer 2 adjacency (ARP/neighbor discovery) cannot be resolved. This commonly occurs during dynamic routing convergence (OSPF, BGP, EIGRP route changes), after failover events when routes are being re-learned, when ECMP zone members change, or when an interface goes down. For connections with the floating connection timeout feature enabled, the flow may be marked for deletion to allow new connections to use the updated routing path. In ICMP flows with zone configurations and inspection enabled, adjacency lookups may fail when reply packets attempt to exit through a different zone member than the request entered.

Recommendation:

If the counter increments briefly during routing changes or failover, this is expected behavior during convergence and requires no action. If the counter grows continuously, verify that routes to affected destinations exist in the routing table and that next-hop addresses are reachable. Check ARP tables to confirm next-hop MAC addresses can be resolved. For ECMP configurations, ensure all zone member interfaces have consistent routing. After failover events with dynamic routing, allow time for route re-learning; if drops persist beyond normal convergence time, investigate routing protocol adjacencies and route propagation. If drops occur on specific flows, use packet capture and connection details to identify the destination and verify end-to-end routing. For ICMP flows in zones with inspection enabled, consider disabling ICMP inspection if asymmetric routing through zone members is required. Contact Cisco TAC if drops persist after routing has stabilized or if they correlate with specific traffic patterns or features.

Syslogs:

None

----------------------------------------------------------------

no-inspect

Inspection resource allocation failed

The firewall dropped a connection because it could not allocate the internal resources needed to perform protocol inspection required by policy. This occurs during connection setup when inspection is configured (via service policy or global inspection) but the system cannot allocate the inspection context from its memory pool. The drop affects any protocol requiring stateful inspection, including DNS, HTTP, SIP, ICMP error handling, IPv6 extension headers, LISP, and others. This is a resource exhaustion condition, not a policy denial—the traffic would otherwise be permitted. Common triggers include sustained high connection rates, memory pressure from other subsystems (SSL VPN, clustering, logging), or reaching platform-specific inspection resource limits. Unlike general memory exhaustion that affects all operations, this counter specifically tracks failures to allocate per-flow inspection state during connection establishment.

Recommendation:

Check overall memory health with 'show memory' and 'show blocks'—look for low free memory or block exhaustion in the 256-byte pool (commonly used for inspection contexts). Review 'show conn' to assess current connection load and compare against platform limits. If memory is healthy but drops persist, examine which inspection engines are configured with 'show service-policy' and consider whether all are necessary for your traffic profile. For SSL VPN deployments, review concurrent session limits and authentication load. If drops correlate with specific traffic types, use 'show asp drop' frame counters to identify which inspection engine is involved, then review that inspection's configuration for resource-intensive options. In high-scale environments, consider disabling inspection for trusted internal-to-internal flows using 'no inspect' in targeted class-maps. If memory exhaustion is confirmed, contact Cisco TAC to investigate potential memory leaks or abnormal resource consumption—reference any relevant defects for your software version. This drop should be rare in normal operation; sustained increments indicate either undersized hardware for the workload or a software issue requiring investigation.

Syslogs:

None directly associated. Related memory allocation failures may generate syslog 747011 (clustering memory allocation failure) or 302311 (app-cache memory allocation failure).

----------------------------------------------------------------

no-ipv6-ipsec

IPsec over IPv6 unsupported

This counter increments when the appliance receives an IPsec ESP packet, IPsec NAT-T ESP packet, or IPsec over UDP ESP packet that is encapsulated in an IPv6 outer header, but the specific IPsec configuration or platform does not support IPv6 as the transport protocol. While modern ASA and FTD releases support IPv6 outer headers for certain IPsec configurations (such as IKEv2 remote access VPN connections starting in ASA 9.0.1), some IPsec deployment scenarios still require IPv4 as the outer transport. This drop occurs during initial packet inspection when the device determines that the IPv6-encapsulated IPsec traffic cannot be processed by the configured IPsec session or is not supported by the platform version.

Recommendation:

Verify that both peers support IPv6 as the IPsec transport protocol. For site-to-site VPN tunnels, ensure that the tunnel endpoints are configured with IPv4 addresses if IPv6 outer headers are not supported in your deployment. For remote access VPN, confirm that your ASA or FTD version and configuration support IKEv2 over IPv6 (available in ASA 9.0.1 and later). If you are running an older software version or using IKEv1, reconfigure the VPN to use IPv4 as the outer transport protocol. Check the IPsec tunnel configuration and crypto map settings to ensure they specify IPv4 endpoints. If this counter increments unexpectedly on a modern platform, verify that the IPsec session was established correctly and that no misconfiguration is forcing IPv6 encapsulation where it is not supported.

Syslogs:

None

----------------------------------------------------------------

no-route-to-peer-nve

No Route to Peer NVE

This counter increments when the device cannot determine how to reach a peer Network Virtualization Endpoint (NVE) during VXLAN or GENEVE tunnel encapsulation. The drop occurs when the routing table lookup fails to find a path to the remote VTEP (Virtual Tunnel Endpoint) IP address through the configured NVE source interface. This typically happens when traffic destined for a VXLAN or GENEVE segment cannot be encapsulated and forwarded because the peer VTEP is unreachable at the IP routing layer. The device has successfully identified the peer VTEP IP (either from static peer configuration or dynamic learning) but cannot resolve the Layer 3 next-hop required to forward the outer tunnel packet.

Recommendation:

Verify that the NVE source interface is configured, operational, and has IP connectivity. Check the routing table to confirm a valid route exists to the peer VTEP IP address via the source interface. For static peer configurations, ensure the peer IP is reachable and that ARP or Neighbor Discovery can resolve the next-hop MAC address. If using dynamic peer discovery with multicast, verify multicast routing is functioning. Common causes include missing static routes, routing protocol issues preventing VTEP reachability, or the source interface being in a down state. Use 'show route' to verify reachability to the peer VTEP IP, and 'show interface' to confirm the NVE source interface status. If the peer VTEP is directly connected, verify Layer 2 connectivity and ARP resolution.

Syslogs:

None.

----------------------------------------------------------------

no-valid-nve-ifc

No valid NVE interface for VNI

This counter increments when the device cannot find the associated VTEP (VXLAN Tunnel Endpoint) or NVE (Network Virtualization Endpoint) interface for a VNI (VXLAN Network Identifier) interface that is attempting to encapsulate outbound traffic. This occurs during VXLAN or GENEVE overlay encapsulation when a packet needs to egress through a VNI interface, but the VNI interface has not been properly bound to an NVE instance. The binding between a VNI interface and its parent VTEP interface is established through the 'vtep-nve' command and is mandatory for overlay operation. Without this association, the device cannot determine which physical or logical interface should serve as the VXLAN/GENEVE tunnel source, and the packet must be dropped. This drop typically occurs in three scenarios: packets egressing with a flow pointing to a VNI interface, cluster-redirected packets with non-VNI flows (such as GRE passenger traffic), or cluster-redirected packets without an associated flow.

Recommendation:

Verify that all VNI interfaces are properly configured with the 'vtep-nve' command to bind them to an NVE instance. Use 'show interface' to confirm VNI interfaces exist and 'show nve 1' to verify the NVE configuration and associated VNI bindings. Check that the NVE source interface is configured and operational. In clustered deployments, ensure that NVE interfaces are not inadvertently disabled or removed from the VTEP configuration, as this can cause deployment failures and make the cluster unusable. If the configuration appears correct but drops persist, verify that the VNI interface's dynamic interface information structure is properly initialized. This drop is always a configuration issue—the VNI-to-VTEP binding must be present for overlay traffic to function. Contact Cisco TAC if the binding appears correct but drops continue.

Syslogs:

None.

----------------------------------------------------------------

non_tcp_syn

Non-SYN TCP Packet Without Existing Connection

The device received a TCP packet that is not a SYN packet and has no existing connection in the connection table. ASA and FTD maintain stateful connection tracking for TCP and require new connections to begin with a SYN packet. When a TCP packet arrives mid-stream (ACK, PST, FIN, RST, or other flags without SYN) and no matching connection exists, the device cannot validate the packet against an established session and drops it. This is expected behavior for a stateful firewall and protects against session hijacking and malformed traffic. The device sends a TCP RST to the sender and generates syslog 106015. Common causes include: asymmetric routing where the initial SYN was processed by a different device; application protocols that attempt to reuse connections after firewall state has timed out; legitimate traffic arriving after a firewall reload or failover cleared the connection table; or inspection engines (such as RTSP or SQL*Net) incorrectly triggering drops on valid traffic due to software defects.

Recommendation:

This counter incrementing is typically normal and expected. Investigate only if legitimate application traffic is failing. First, check for syslog 106015 messages to identify the specific source/destination and TCP flags involved. If the traffic is legitimate: (1) Verify routing is symmetric—use packet captures on both interfaces to confirm the SYN packet traverses the same firewall. (2) Check for asymmetric routing in cluster deployments; enable director/forwarder roles and review cluster health. (3) If specific application protocols are affected (RTSP, SQL*Net, Oracle), check whether protocol inspection is enabled and review known defects (CSCwr51629 for RTSP, CSCwh14863 for SQL*Net clustering). Disabling inspection for the affected protocol may resolve the issue. (4) For applications that must pick up mid-stream (rare), consider tcp-state-bypass, but note this disables stateful protections and is incompatible with sequence number randomization. (5) Increase connection timeouts if applications have long idle periods between packets. If drops occur after failover or reload, this is expected—applications will re-establish connections. Contact TAC if legitimate traffic fails consistently and asymmetric routing has been ruled out.

Syslogs:

106015

----------------------------------------------------------------

np-context-removed

Virtual context removed during flow creation

This counter increments when the system attempts to create a new connection in a virtual security context that is currently being removed or has already been removed. This occurs exclusively in multi-context mode on multi-core platforms when there is a timing window between an administrator removing a context and the system tearing down all flows associated with that context. One CPU core may be processing the context removal while another core simultaneously attempts to establish a new connection for traffic arriving on an interface assigned to that context. The flow creation fails because the system cannot safely associate the new connection with a context that is in the process of being destroyed.

Recommendation:

This is a normal, transient condition during context removal and requires no action. The counter typically appears when an administrator executes 'no context <name>' or removes a context through the management interface. Any new connection attempts to the removed context will be dropped until the context removal completes. If this counter increments without any recent context configuration changes, verify that contexts are not being automatically removed due to configuration errors or resource exhaustion. In steady-state operation with stable context configuration, this counter should remain at zero.

Syslogs:

None. Context removal generates syslog 504002 (Security context was removed from the system).

----------------------------------------------------------------

np-midpath-cp-event-failure

Datapath unable to send critical event to control plane

The datapath failed to communicate a critical event to the control plane during SSL/TLS inspection or VPN connection processing. This occurs when the system cannot allocate memory for the event message or when the internal event queue between the datapath and control plane is full. The affected connection is terminated to prevent inconsistent state between the datapath and control plane. This counter typically appears on multi-core platforms during periods of high connection load, particularly when SSL/TLS decryption inspection or AnyConnect VPN connections are active. Common triggers include memory pressure from sustained high connection rates, large numbers of concurrent SSL inspections, or resource exhaustion during connection teardown when final statistics must be reported to the control plane.

Recommendation:

This counter indicates a resource exhaustion condition that requires investigation. Check system memory utilization with 'show memory' and 'show blocks' to identify memory pressure. Review 'show asp event dp-cp' to examine the health of datapath-to-control-plane event queues; look for queue full conditions or high enqueue failure rates. If the counter increments during high SSL/TLS inspection load, consider reducing the number of concurrent inspected connections or increasing system memory. For VPN-related occurrences, review AnyConnect session counts and connection rates. Persistent increments of this counter indicate the system is undersized for the traffic load or that a memory leak may be present. Collect a troubleshooting bundle and contact Cisco TAC if the counter continues to increment after addressing resource constraints, as this may indicate a software defect requiring deeper analysis.