show asp drop コマンドの使用方法
Table of Contents
show asp drop コマンドの使用方法
高速セキュリティパスでドロップされたパケットまたは接続をデバッグするには、特権 EXEC モードで show asp drop コマンドを使用します。
show asp drop [ flow [ flow_drop_reason ] | frame [ frame_drop_reason ]]
使用上のガイドライン
show asp drop コマンドは、高速セキュリティパスによってドロップされたパケットまたは接続を表示します。この情報は、問題のトラブルシューティングに役立つ場合があります。高速セキュリティパスの詳細については、一般的な操作のコンフィギュレーション ガイドを参照してください。この情報はデバッグの目的でのみ使用されます。また、情報の出力は変更される可能性があります。このコマンドを使用したシステムデバッグについて支援が必要な場合は、Cisco TAC にお問い合わせください。
次の項では、各ドロップ理由の名前、説明、および推奨事項を示します。
フレームのドロップ理由
This counter will increment when the appliance receives an IPSec NAT-T keepalive message. NAT-T keepalive messages are sent from the IPSec peer to the appliance to keep NAT/PAT flow information current in network devices between the NAT-T IPSec peer and the appliance.
If you have configured IPSec NAT-T on your appliance, this indication is normal and doesn't indicate a problem. If NAT-T is not configured on your appliance, analyze your network traffic to determine the source of the NAT-T traffic.
This counter will increment when the appliance receives an IPSec over UDP keepalive message. IPSec over UDP keepalive messages are sent from the IPSec peer to the appliance to keep NAT/PAT flow information current in network devices between the IPSec over UDP peer and the appliance. Note - These are not industry standard NAT-T keepalive messages which are also carried over UDP and addressed to UDP port 4500.
If you have configured IPSec over UDP on your appliance, this indication is normal and doesn't indicate a problem. If IPSec over UDP is not configured on your appliance, analyze your network traffic to determine the source of the IPSec over UDP traffic.
This counter will increment when the appliance receives a packet on an IPSec connection which is not an AH or ESP protocol. This is not a normal condition.
If you are receiving many IPSec not AH or ESP indications on your appliance, analyze your network traffic to determine the source of the traffic.
This counter will increment when the appliance receives an IPSec ESP packet, IPSec NAT-T ESP packet or an IPSec over UDP ESP packet encapsulated in an IP version 6 header. The appliance does not currently support any IPSec sessions encapsulated in IP version 6.
This counter will increment when the appliance receives a packet on an IPSec connection which has negotiated NAT-T but the packet is not addressed to the NAT-T UDP destination port of 4500 or had an invalid payload length.
This counter will increment when the appliance receives a packet on an IPSec connection which has negotiated IPSec over UDP but the packet has an invalid payload length.
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.
If you have configured IPSec LAN-to-LAN on your appliance, this indication is normal and doesn't 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.
This counter will increment when the appliance receives a packet which should have been encrypted but was not. The packet matched the inner header security policy check of a configured and established IPSec connection on the appliance but was received unencrypted. This is a security issue.
This counter will increment when the appliance receives a packet which should have been encrypted but was not. The packet matched the inner header security policy check of a configured and established IPSec connection on the appliance but was received unencrypted. This is a security issue.
This counter will increment when the appliance receives a packet associated with an IPSec connection which is in the process of being deleted.
This counter will increment when the appliance receives a packet associated with an IPSec connection on a flow that does not have encrypt flags on.
It is possible to see this counter increment as part of normal operation. However, if the counter is rapidly incrementing and there is a traffic disruption, then this may be caused by a misconfiguration or a software defect.
This counter will increment when the security appliance receives a packet associated with an SVC connection that is in the process of being deleted.
This is a normal condition when the SVC connection is torn down for any reason. If this error occurs repeatedly or in large numbers, it could indicate that clients are having network connectivity issues.
This counter will increment when the security appliance receives a packet from an SVC or the control software that it is unable to decode.
This indicates that a software error should be reported to the Cisco TAC. The SVC or security appliance could be at fault.
This counter will increment when the security appliance receives a packet from an SVC or the control software where the calculated and specified lengths do not match.
This indicates that a software error should be reported to the Cisco TAC. The SVC or security appliance could be at fault.
This counter will increment when the security appliance receives a packet from an SVC where the data type is unknown.
Validate that the SVC being used by the client is compatible with the version of security appliance software.
This counter will increment when the security appliance receives an Address Renew Response message from an SVC. The SVC should not be sending this message.
This counter will increment when there is not enough space before the packet data to prepend a MAC header in order to put the packet onto the network.
This counter will increment when the interface that the encrypted data was received upon cannot be found in order to inject the decrypted data.
If an interface is shut down during a connection, this could happen; re-enable/check the interface. Otherwise, this indicates that a software error should be reported to the Cisco TAC.
This counter will increment when the security appliance cannot determine the SVC session that this data should be transmitted over.
This counter will increment when the security appliance cannot grab the lock for the SVC session that this data should be transmitted over.
This condition should never be encountered during normal operation and may indicate a software problem with the appliance. Contact the Cisco Technical Assistance Center (TAC) if this error occurs.
This counter will increment when the security appliance encounters an error during decompression of data from an SVC.
This indicates that a software error should be reported to the Cisco TAC. The SVC or security appliance could be at fault.
This counter will increment when the security appliance encounters an error during compression of data to an SVC.
This indicates that a software error should be reported to the Cisco TAC. The SVC or security appliance could be at fault.
This counter will increment when the security appliance is unable to find an L2 MAC header for data received from an SVC.
This counter will increment when the security appliance is finds an invalid L2 MAC header attached to data received from an SVC.
This counter will increment when the security appliance is finds an invalid L2 MAC length attached to data received from an SVC.
This counter will increment when the security appliance needs to drop data because an SVC is temporarily not accepting any more data.
Use packet capture of type asp-drop to determine the direction of the packet. Most often this indicates that the client is unable to accept more data. On rare occasion, the counter can indicate the appliance cannot handle the inbound traffic if the packet direcion is towards the appliance.
This counter is incremented when a packet to be sent to the SVC is not permitted to be fragmented or when there are not enough data buffers to fragment the packet.
Increase the MTU of the SVC to reduce fragmentation. Avoid using applications that do not permit fragmentation. Decrease the load on the device to increase available data buffers.
This counter is incremented when a packet to be sent to an AnyConnect client is not able to be compressed.
This counter is incremented when a packet received from an AnyConnect client is not able to be decompressed.
This counter is incremented when the appliances is unable to create a VPN handle because the VPN handle already exists.
It is possible to see this counter increment as part of normal operation However, if the counter is rapidly incrementing and there is a major malfunction of vpn-based applications, then this may be caused by a software defect. Contact the Cisco TAC to investigate the issue further.
This counter is incremented when an IPSec operation is attempted but fails due to an internal locking error.
This condition should never be encountered during normal operation and may indicate a software problem with the appliance. Contact the Cisco Technical Assistance Center (TAC) if this error occurs.
This counter is incremented when the appliance wants to forward a block and the flow referred to by the VPN Handle is different than the flow associated with the block.
This is not a normal occurrence. Please perform a "show console-output" and forward that output to CISCO TAC for further analysis
This counter is incremented when a packet for a VPN flow is dropped due to the flow failing to be reclassified after a VPN state change.
This counter is incremented when a packet for a VPN flow arrives that requires reclassification due to VPN CLI or Tunnel state changes. If the flow no longer matches the existing policies, then the flow is freed and the packet dropped.
This condition should never be encountered during normal operation and may indicate a software problem with the appliance. Contact the Cisco Technical Assistance Center (TAC) if this error occurs.
This counter will increment when the security appliance receives a packet that requires encryption or decryption, and the ASP VPN context required to perform the operation is no longer valid.
When a packet is decrypted the inner packet is examined against the crypto map configuration. If the packet matches a different crypto map entry than the one it was received on it will be dropped and this counter will increment. A common cause for this is two crypto map entries containing similar/overlapping address spaces.
Check your VPN configuration for overlapping networks. Verify the order of your crypto maps and use of 'deny' rules in ACLs.
This counter is incremented when an IPSec packet is received with an inner IP header that does not match the configured policy for the tunnel.
Verify that the crypto ACLs for the tunnel are correct and that all acceptable packets are included in the tunnel identity. Verify that the box is not under attack if this message is repeatedly seen.
This counter will increment when the appliance receives a packet matching an entry in the security policy database (i.e. crypto map) but the security association is in the process of being negotiated; its not complete yet.
This counter will also increment when the appliance receives a packet matching an entry in the security policy database but the security association has been or is in the process of being deleted. The difference between this indication and the 'Tunnel has been torn down' indication is that the 'Tunnel has been torn down' indication is for established flows.
This counter will increment when the appliance attempts to forward a layer-2 packet to a rate-limited control point service routine and the rate limit (per/second) is now being exceeded. Currently, the only layer-2 packets destined for a control point service routine which are rate limited are ARP packets. The ARP packet rate limit is 500 ARPs per second per interface.
This counter is incremented and the packet is dropped when there is no memory to create data structure for punting a packet to Control Point.
No action needs to be taken if this condition is transient. If this condition persists due to low memory, then system upgrade might be necessary.
This counter is incremented and the packet is dropped when punt queue limit is exceeded, an indication that a bottle-neck is forming at Control Point.
This counter is incremented when the flow is being freed and all packets queued for inspection are dropped.
This counter is incremented when the security appliance receives a frame belonging to an unsupported link-level protocol or if the L3type specified in the frame is not supported by the appliance. The packet is dropped.
This counter is incremented and the packet is dropped when the appliance receives an IP packet whose computed checksum of the IP header does not match the recorded checksum in the header.
The packet corruption may be caused by a bad cable or noise on the line. It may also be that a peer is sending corrupted packets and an attack is in progress. Please use the packet capture feature to learn more about the origin of the packet.
This counter is incremented when the security appliance receives an IP packet that has an unsupported version in version field of IP header. Specifically, if the packet does not belong to version 4 or version 6. The packet is dropped.
Verify that other devices on connected network are configured to send IP packets belonging to versions 4 or 6 only.
This counter is incremented when the security appliance receives an IP packet whose value of ttl(time to live) has exceeded the allowed limit. Specifically if the packet has ttl value of 1, when set connection decrement-ttl command is configured, or less than 1, the packet is dropped.
This counter is incremented when the security appliance receives an IPv6 packet whose value of hop-limit has exceeded the allowed limit. Specifically if the packet has hop-limit less than 1, the packet is dropped.
This counter is incremented when the security appliance receives an IPv4 or IPv6 packet in which the header length or total length fields in IP header are not valid or do not conform to the received packet length.
This counter is incremented when the fragmentation module on the security appliance receives or tries to send a fragmented packet that does not belong IP version 4 or version 6. The packet is dropped.
Verify mtu of device and other devices on connected network to determine why the device is processing such fragments.
This counter is incremented when the security appliance receives a TCP packet whose size is smaller than minimum-allowed header length or does not conform to the received packet length.
This counter is incremented when the security appliance receives a UDP packet whose size as calculated from the fields in header is different from the measured size of packet as received from the network.
This counter is incremented when the security appliance recieves a SCTP packet whose common header size is less than the required common header size (12 bytes).
This counter is incremented when the security appliance has tried to obtian an adjacency and could not obtain mac-address for next hop. The packet is dropped.
Configure a capture for this drop reason and check if a host with specified destination address exists on connected network or is routable from the device.
This counter is incremented when the security appliance has tried to obtian an adjacency and could not obtain mac-address for next hop. The packet is dropped.
Configure a capture for this drop reason and check if a host with specified destination address exists on connected network or is routable from the device.
This counter is incremented when the security appliance has tried to obtian an adjacency and could not obtain mac-address for next hop. The packet is dropped.
Configure a capture for this drop reason and check if a host with specified destination address exists on connected network or is routable from the device.
This counter is incremented when the security appliance has tried to obtian an adjacency and could not obtain mac-address for next hop. The packet is dropped.
Configure a capture for this drop reason and check if a host with specified destination address exists on connected network or is routable from the device.
This counter is incremented when the security appliance has tried to obtian an adjacency and could not obtain mac-address for next hop. The packet is dropped.
Configure a capture for this drop reason and check if a host with specified destination address exists on connected network or is routable from the device.
This counter is incremented when the appliance in transparent mode receives a non-IP packet, destined to it's MAC address, but there is no corresponding service running on the appliance to process the packet.
Verify if the appliance is under attack. If there are no suspicious packets, or the device is not in transparent mode, this counter is most likely being incremented due to a software error. Attempt to capture the traffic that is causing the counter to increment and contact the Cisco TAC.
This counter is incremented when the security appliance tries to send a packet out of an interface and does not find a route for it in routing table.
This counter is incremented when the security appliance decapsulates a VXLAN packet which has an invalid segment-id.
This counter is incremented when the TVI interface processes a VXLAN packet which has an invalid segment-id.
This counter is incremented when the security appliance fails to lookup for the out tag for a given in tag when tag switching is enabled on the VNI interface.
This counter is incremented when the security appliance fails to identify the VNI interface by a given segment-id.
This counter is incremented when the security appliance fails to identify the NVE interface for a VNI interface.
This counter is incremented when the security appliance fails to get IP and MAC address of a peer NVE.
This counter is incremented when the security appliance locates different egress interface by STS and NAT.
This counter is incremented when the security appliance decapsulates a VXLAN packet in FP which has an invalid segment-id.
This counter is increamented when the security appliance receives a UDP packet with correct VXLAN destination port number but failed to decode the VXLAN header.
This counter is increamented when the security appliance receives a through-the-box UDP packet with correct VXLAN destination port number but failed to decode the VXLAN header.
This counter is increamented when the security appliance receives a VXLAN packet with incorrect checksum value in UDP header.
This counter is increamented when the security appliance receives a VXLAN packet from an NVE peer that is not configured.
This counter is incremented when the security appliance fails to get the multicast group IP from the VNI interface.
Verify that in the absence of a configured peer NVE, the VNI interface has a valid multicast group IP configured on it.
This counter is incremented when the security appliance fails to find the peer VTEP IP for an inner destnation IP for VXLAN encapsulation.
Verify that in show arp vtep-mapping/show mac-address-table vtep-mapping/show ipv6 neighbor vtep-mapping, the VTEP IP is present for the desired remote inner host.
This counter is incremented when ip-verify is configured on an interface and the security appliance receives a packet for which the route lookup of source-ip did not yield the same interface as the one on which the packet was received.
Trace the source of traffic based on source-ip printed in syslog below and investigate why it is sending spoofed traffic.
This counter is incremented when a drop rule is hit by the packet and gets dropped. This rule could be a default rule created when the box comes up, when various features are turned on or off, when an acl is applied to interface or any other feature etc. Apart from default rule drops, a packet could be dropped because of:
This counter is incremented when the decrypt and encrypt tunnel is owned by the same interface and same-security-traffic is not configured.
This counter is incremented and the packet is dropped when flow creation fails due to a system resource limitation. The resource limit may be either:
- Observe if connection count reaches the system connection limit with the command "show resource usage".
This counter is incremented when a newly created flow is inserted into flow hash table and the insertion failed because the hash table was full. The flow and the packet are dropped. This is different from counter that gets incremented when maximum connection limit is reached.
This message signifies lack of resources on the device to support an operation that should have been successful. Please check if the connections in the 'show conn' output have exceeded their configured idle timeout values. If so, contact the Cisco Technical Assistance Center (TAC).
This counter will increment when the appliance receives an IPSec ESP packet addressed to the appliance which specifies a SPI (security parameter index) not currently known by the appliance.
Occasional invalid SPI indications are common, especially during rekey processing. Many invalid SPI indications may suggest a problem or DoS attack. If you are experiencing a high rate of invalid SPI indications, analyze your network traffic to determine the source of the ESP traffic.
This counter is incremented and the packet is dropped if an IPv6 packet is received with an unsupported IPv6 extension header. The supported IPv6 extension headers are: TCP, UDP, ICMPv6, ESP, AH, Hop Options, Destination Options, and Fragment. The IPv6 routing extension header is not supported, and any extension header not listed above is not supported. IPv6 ESP and AH headers are supported only if the packet is through-the-box. To-the-box IPv6 ESP and AH packets are not supported and will be dropped.
This error may be due to a misconfigured host. If this error occurs repeatedly or in large numbers, it could also indicate spurious or malicious activity such as an attempted DoS attack.
Under normal conditions, this may be seen when the appliance has already closed a connection, and the client or server still believe the connection is open, and continue to transmit data. Some examples where this may occur is just after a 'clear local-host' or 'clear xlate' is issued. Also, if connections have not been recently removed, and the counter is incrementing rapidly, the appliance may be under attack. Capture a sniffer trace to help isolate the cause.
This counter is incremented and the packet is dropped when the appliance receives a TCP packet whose computed TCP checksum does not match the recorded checksum in TCP header.
The packet corruption may be caused by a bad cable or noise on the line. It may also be that a TCP endpoint is sending corrupted packets and an attack is in progress. Please use the packet capture feature to learn more about the origin of the packet. To allow packets with incorrect TCP checksum disable checksum-verification feature under tcp-map.
This counter is incremented and the packet is dropped when the appliance receives a TCP packet with invalid TCP flags in TCP header. Example a packet with SYN and FIN TCP flags set will be dropped.
The packet corruption may be caused by a bad cable or noise on the line. It may also be that a TCP endpoint is sending corrupted packets and an attack is in progress. Please use the packet capture feature to learn more about the origin of the packet.
This counter is incremented and the packet is dropped when the appliance receives a TCP packet with reserved flags set in TCP header.
The packet corruption may be caused by a bad cable or noise on the line. It may also be that a TCP endpoint is sending corrupted packets and an attack is in progress. Please use the packet capture feature to learn more about the origin of the packet. To allow such TCP packets or clear reserved flags and then pass the packet use reserved-bits configuration under tcp-map.
This counter is incremented and the packet is dropped when the appliance receives a TCP packet with a non-standard TCP header option.
To allow such TCP packets or clear non-standard TCP header options and then allow the packet, use tcp-options configuration under tcp-map.
This counter is incremented and the packet is dropped when the appliance receives a TCP packet with data length greater than the MSS advertized by peer TCP endpoint.
This counter is incremented and the packet is dropped when the appliance receives a TCP SYN-ACK packet with data.
The packet corruption may be caused by a bad cable or noise on the line. It may also be that a TCP endpoint is sending corrupted packets and an attack is in progress. Please use the packet capture feature to learn more about the origin of the packet.
This counter is incremented and the packet is dropped when the appliance receives a TCP SYN packet with data.
This counter is incremented and the packet is dropped when the appliance recevies a TCP SYN packet from the server, when an embryonic TCP connection is already open.
This counter is incremented and the packet is dropped when the appliance recevies new TCP data packet from an endpoint which had sent a FIN to close the connection.
This counter is incremented and the packet is dropped when appliance receives an invalid TCP packet during three-way-handshake. Example SYN-ACK from client will be dropped for this reason.
This counter is incremented and the packet is dropped when appliance receives a RST or a FIN packet with incorrect TCP sequence number.
This counter is incremented and the packet is dropped when appliance receives a SYN or SYN-ACK packet during three-way-handshake with incorrect TCP sequence number.
This counter is incremented and the packet is dropped when appliance receives a SYN-ACK packet during three-way-handshake with incorrect TCP acknowledgement number.
This counter is incremented and the packet is dropped when appliance receives a TCP SYN packet on an established TCP connection.
This counter is incremented and the packet is dropped when appliance receives a TCP SYN-ACK packet on an established TCP connection.
This counter is incremented and the packet is dropped when appliance receives a TCP data packet with sequence number beyond the window allowed by the peer TCP endpoint.
This counter is incremented and the packet is dropped when appliance receives a TCP packet with acknowledgement number greater than data sent by peer TCP endpoint.
This counter is incremented and the packet is dropped when appliance receives a TCP packet with control flag like SYN, FIN or RST on an established connection just after the appliance has taken over as active unit.
This counter is incremented and the packet is dropped when appliance receives a TCP ACK packet from client during three-way-handshake and the sequence number is not next expected sequence number.
This counter is incremented and the packet is dropped when appliance receives an out-of-order TCP packet on a connection and there is no buffer space to store this packet. Typically TCP packets are put into order on connections that are inspected by the appliance or when packets are sent to SSM for inspection. There is a default queue size and when packets in excess of this default queue size are received they will be dropped.
This counter is incremented and the packet is dropped when the security appliance receives an out-of-order TCP packet on a connection and there are no more global buffers available. Typically TCP packets are put into order on connections that are inspected by the security appliance or when packets are sent to the SSM for inspection. When the global Out-of-Order buffer queue is full, the packet will be dropped and this counter will increment.
This is a temporary condition when all global buffers are used. If this counter is constantly incrementing, then please check your network for large amounts of Out-of-Order traffic, which could be caused by traffic of the same flow taking different routes through the network.
This counter is incremented and the packet is dropped when a queued out of order TCP packet has been held in the buffer for too long.Typically, TCP packets are put into order on connections that are inspected by the security appliance or when packets are sent to the SSM for inspection. When the next expected TCP packet does not arrive within a certain period, the queued out of order packet is dropped.
The next expected TCP packet may not arrive due to congestion in the network which is normal in a busy network. The TCP retransmission mechanism in the end host will retransmit the packet and the session will continue.
This counter is incremented and the packet is dropped when appliance receives a TCP SYN or TCP RST packet on an established connection with sequence number within window but not next expected sequence number.
This counter is incremented and the packet is dropped when appliance receives a retransmitted data packet and the data has been acknowledged by the peer TCP endpoint.
This counter is incremented and the packet is dropped when appliance receives a retransmitted data packet that is already in our out of order packet queue.
This counter is incremented and the packet is dropped when TCP packet with timestamp header option fails the PAWS (Protect Against Wrapped Sequences) test.
To allow such connections to proceed, use tcp-options configuration under tcp-map to clear timestamp option.
This reason is given for dropping a TCP packet during TCP connection establishment phase when the connection limit has been exceeded. The connection limit is configured via the 'set connection conn-max' action command.
If this is incrementing rapidly, check the syslogs to determine which host's connection limit is reached. The connection limit may need to be increased if the traffic is normal, or the host may be under attack.
This reason is given for dropping a packet when the connection limit or host connection limit has been exceeded. If this is a TCP packet which is dropped during TCP connection establishment phase due to connection limit, the drop reason 'TCP connection limit reached' is also reported.
If this is incrementing rapidly, check the syslogs to determine which host's connection limit is reached. The connection limit may need to be increased if the traffic is normal, or the host may be under attack.
This counter is incremented and the packet is dropped when check-retranmission feature is enabled and a partial TCP retransmission was received.
This counter is incremented and the packet is dropped when no matching association exist for this packet.
This counter is incremented and the packet is dropped when SCTP packet size is less then the combined size of common header and chunk header.
This counter is incremented and the packet is dropped when the SCTP chunk length value is less then the size of chunk header.
This counter is incremented and the packet is dropped when the SCTP chunk length value is less then the size of INIT chunk.
This counter is incremented and the packet is dropped when the SCTP parameter length value is less then the size of parameter header.
This counter is incremented and the packet is dropped when SCTP restart INIT chunk contains new address.
This counter is incremented and the packet is dropped when the SCTP chunk length value is less then the size of INIT ACK chunk.
This counter is incremented and the packet is dropped when SCTP INIT chunk is received in SHUTDOWN state.
This counter is incremented and the packet is dropped when SCTP INIT ACK chunk is received with no matching INIT.
This drop can happen in a scenarios like when there are redundant paths between client and server or due to some congestion in the network which could cause INIT ACK to be received after the connection created for INIT is torn down. If this error occurs in large numbers, please use packet capture feature to help isolate the issue.
This counter is incremented and the packet is dropped when SCTP INIT chunk contains 0 value initiate tag.
This counter is incremented and the packet is dropped when SCTP INIT ACK chunk contains 0 value initiate tag.
This counter is incremented and the packet is dropped when SCTP INIT chunk receive-window value is too small (less than 1500).
This counter is incremented and the packet is dropped when SCTP INIT ACK chunk receive-window value is too small (less than 1500).
This counter is incremented and the packet is dropped when SCTP INIT chunk contains 0 value inbound/outbound stream count.
This counter is incremented and the packet is dropped when SCTP INIT ACK chunk contains 0 value inbound/outbound stream count.
This counter is incremented and the packet is dropped when SCTP INIT ACK chunk contains invalid parameter length value.
This counter is incremented and the packet is dropped when SCTP INIT chunk contains invalid ipv4 parameter length value.
This counter is incremented and the packet is dropped when SCTP INIT ACK chunk contains invalid ipv4 parameter length value.
This counter is incremented and the packet is dropped when SCTP INIT chunk contains invalid ipv6 parameter length value.
This counter is incremented and the packet is dropped when SCTP INIT ACK chunk contains invalid ipv6 parameter length value.
This counter is incremented and the packet is dropped when SCTP COOKIE ECHO chunk is received without an association.
This counter is incremented and the packet is dropped when SCTP COOKIE ACK chunk is received without an association.
This counter is incremented and the packet is dropped when SCTP COOKIE ECHO chunk contains an echoed cookie with a different length.
This counter is incremented and the packet is dropped when SCTP COOKIE ECHO chunk is received in association CLOSED state.
This counter is incremented and the packet is dropped when SCTP COOKIE ECHO chunk is received during association shutdown.
This counter is incremented and the packet is dropped when SCTP COOKIE ACK chunk is not received in COOKIE ECHOED state.
This counter is incremented and the packet is dropped when SCTP SHUTDOWN chunk is not received in valid state.
This counter is incremented and the packet is dropped when SCTP SHUTDOWN ACK chunk is not received in valid state.
This counter is incremented and the packet is dropped when SCTP SHUTDOWN COMPLETE chunk is not received in valid state.
This counter is incremented and the packet is dropped when SCTP SACK chunk is not received in valid state.
This counter is incremented and the packet is dropped when SCTP FORWARD CUMULATIVE TSN chunk is not received in valid state.
This counter is incremented and the packet is dropped when SCTP FORWARD CUMULATIVE TSN chunk length is too small.
This counter is incremented and the packet is dropped when SCTP FORWARD CUMULATIVE TSN gap is out of range (100).
This counter is incremented and the packet is dropped when SCTP INIT (restart) chunk contains IP address that is not in previous INIT.
This counter is incremented and the packet is dropped when SCTP INIT chunk contains contains ASCONF support without AUTH support.
This counter is incremented and the packet is dropped when SCTP INIT chunk contains REDUNDANCY support without AUTH support.
This counter is incremented and the packet is dropped when SCTP chunk bundle included INIT, INIT_ACK, or SHUTDOWN_COMPLETE.
This counter is incremented and the packet is dropped when SCTP packet has control chunks present after data chunks and is dropped.
This counter is incremented and the packet is dropped when SCTP chunk contains unrecognizable parameter.
SCTP chunk parameter SUPPORTED ADDRESS contains invalid length:n This counter is incremented and the packet is dropped when SCTP INIT/INIT ACK chunk parameter SUPPORTED ADDRESS contains invalid length (< 4).
This counter is incremented and the packet is dropped when SCTP packet contains more than one AUTH chunk.
This counter is incremented and the packet is dropped when SCTP packet containing INIT ACK chunk is received in non-cookie-wait state.
This counter is incremented and the packet is dropped when packet containing INIT/ABORT chunk has zero verification tag.
This counter is incremented and the packet is dropped when packet contains verification tag that does not match association tag.
This counter is incremented and the packet is dropped when SHUTDOWN COMPLETE is received unexpectedly.
This counter is incremented and the packet is dropped when SCTP DATA chunk is received in invalid state.
This counter is incremented and the packet is dropped when SCTP DATA chunk contains invalid stream id.
This counter is incremented and the packet is dropped when SCTP DATA chunk length is greater than receive window.
This counter is incremented and the packet is dropped when a duplicate SCTP DATA stream is received.
This counter is incremented and the packet is dropped when the SCTP out of order packet queue exceeds the default limit 20.
This counter is incremented and the data chunk is dropped when an out of order SCTP data chunk has been held in the buffer for 30 seconds.
This counter is incremented when the security appliance recieves a SCTP packet with a fixme drop reason
This counter is incremented and the chunk is dropped when number of out of order chunks exceeds the limit(50/stream) for the stream.
This counter is incremented and the fragmented chunks are deleted from the reassembly queue when those fragmented chunks has been held in the reassembly queue for 30 seconds.
This counter is incremented and the fragmented chunks are deleted from the reassembly queue after the number of fragments in reassembly queue reaches its maximum(6).
This counter is incremented and the reassembly datagram is deleted from the stream reassembly queue(all fragments) after the total bytesize of chunks in the dgram reassembly queue reaches its maximum(8192bytes).
This counter is incremented and the chunk is dropped when first out of order chunk is received after the number ofStreams in Reorder reaches its maximum(64*number of cpu cores).
This counter is incremented and the reassembly datagram will not be created for the new incoming fragments after the number of datagrams in reassembly queues in ASA reaches its maximum(125/core) We do repacking if the fragment is bundled else we drop the whole packet.
This counter is incremented and all fragments in reassembly queue will be deleted including the fragment which is not yet been queued.
This counter is incremented and the packet is dropped when SCTP SHUTDOWN chunk is received without an association.
This counter is incremented and the packet is dropped when SCTP SHUTDOWN ACK chunk is received without an association.
This counter is incremented and the packet is dropped when SCTP SHUTDOWN COMPLETE chunk is received without an association.
This counter is incremented and the packet is dropped when SCTP SACK chunk is received without an association.
This counter is incremented and the packet is dropped when SCTP HEARTBEAT chunk is received without an association.
This counter is incremented and the packet is dropped when SCTP HEARTBEAT ACK chunk is received without an association.
This counter is incremented and the packet is dropped when check-retranmission feature is enabled and a TCP retranmission with different data from the original packet was received.
This counter is incremented and the packet is dropped when window size advertized by TCP endpoint is drastically changed without accepting that much data.
This counter is incremented and the packet is dropped when the appliance receives a TCP packet with TCP option length 0, which is invalid for non-NOP option.
This counter is incremented when rate-limiting (policing) is configured on an egress/ingress interface and the egress/ingress traffic rate exceeds the burst rate configured. The counter is incremented for each packet dropped.
Investigate and determine why the rate of traffic leaving/entering the interface is higher than the configured rate. This may be normal, or could be an indication of virus or attempted attack.
When QoS config is changed or removed, the existing packets in the output queues awaiting transmission are dropped and this counter is incremented.
Under normal conditions, this may be seen when the QoS configuration has been changed by the user. If this occurs when no changes to QoS config were performed, please contact Cisco Technical Assistance Center (TAC).
This counter will increment when the appliance attempts to perform a crypto operation on a packet and the crypto operation fails. This is not a normal condition and could indicate possible software or hardware problems with the appliance
If you are receiving many bad crypto indications your appliance may need servicing. You should enable syslog 402123 to determine whether the crypto errors are hardware or software errors. You can also check the error counter in the global IPSec statistics with the 'show ipsec stats' CLI command. If the IPSec SA which is triggering these errors is known, the SA statistics from the 'show ipsec sa detail' command will also be useful in diagnosing the problem.
The minimal length of SSL first handshake record should be 11 bytes. If the first record is less than 11 bytes, the packet will be dropped.
This counter is incremented for invalid SSL record type that has first SSL record less than 11 bytes. This invalid type received from the remote peer is treated as a fatal error and the SSL packets that encounter this error must be dropped.
The minimal length of SSL handshake record should be 4 bytes. If the handshake record is less than 4 bytes, the packet will be dropped.
This counter is incremented for invalid SSL record type that has SSL record less than 4 bytes. This invalid type received from the remote peer is treated as a fatal error and the SSL packets that encounter this error must be dropped.
The minimal length of SSL handshake alert should be 2 bytes. If the handshake record is less than 2 bytes, the packet will be dropped.
This counter is incremented for invalid SSL record type that has SSL alert less than 2 bytes. This invalid type received from the remote peer is treated as a fatal error and the SSL packets that encounter this error must be dropped.
This counter will increment when the appliance attempts to perform a crypto operation on a packet and the crypto operation fails. This is not a normal condition and could indicate possible software or hardware problems with the appliance.
If you are receiving many bad crypto indications your appliance may need servicing. You should enable syslog 402123 to determine whether the crypto errors are hardware or software errors. You can also check the error counter in the global IPSec statistics with the 'show ipsec stats' CLI command. If the IPSec SA which is triggering these errors is known, the SA statistics from the 'show ipsec sa detail' command will also be useful in diagnosing the problem.
- receives an IPv4 multicast packet when the packets multicast MAC address doesn't match the packets multicast destination IP address
For detailed description and syslogs for IP audit attack checks please refer the ip audit signature section of command reference guide
This counter is incremented and every packet is dropped when data-plane does not have a valid policy installed in the security context
3) In routed or transparent mode and receives an IPv4 or IPv6 packet with same source and destination IP addresses
1 and 2) Determine if an external user is trying to compromise the protected network. Check for misconfigured clients.
3) If this message counter is incrementing rapidly, an attack may be in progress. Use the packet capture feature to capture type asp packets, and check the source MAC address in the packet to see where they are coming from.
This counter is incremented when any unicast packet with ip options or a multicast packet with ip-options that have not been configured to be accepted, is received by the security appliance. The packet is dropped.
The packet corruption could be caused by a bad cable, interface card, line noise, or software defect. If the interface appears to be functioning properly, then report the problem to Cisco TAC.
If a through-the-box packet arrives at an appliance or context in a Standby state and a flow is created, the packet is dropped and the flow removed. This counter will increment each time a packet is dropped in this manner.
This counter should never be incrementing on the Active appliance or context. However, it is normal to see it increment on the Standby appliance or context.
This counter will increment when the appliance is configured for Layer 2 switching and the appliance does a Layer 2 destination MAC address lookup which fails. Upon the lookup failure, the appliance will begin the destination MAC discovery process and attempt to find the location of the host via ARP and/or ICMP messages.
This is a normal condition when the appliance is configured for Layer 2 switching. You can also execute (show mac-address-table) to list the L2 MAC address locations currently discovered by the appliance.
This counter will be incremented when the ingress interface belongs to a bridge-group and leaving via an interface which belongs to a different bridge-group or a L3 interface without nameif configured on the ingress BVI interface.
Analyze the packets to determine source of unsuported packets that are tried to punt on BVI interface.
This counter will increment when the appliance/context is configured for transparent mode and the appliance determines that the destination interface's L2 MAC address is the same as its ingress interface.
This is a normal condition when the appliance/context is configured for transparent mode. Since the appliance interface is operating in promiscuous mode, the appliance/context receives all packets on the local LAN seqment.
This counter is incremented when the security appliance tries to inject a new or cached packet belonging to a flow that has already expired.It is also incremented when the appliance attempts to send an rst on a tcp flow that has already expired or when a packet returns from IDS blade but the flow had already expired. The packet is dropped
This counter is incremented when the security appliance tries to inject a new or cached packet belonging to a flow that has already expired.It is also incremented when the appliance attempts to send an rst on a tcp flow that has already expired or when a packet returns from IDS blade but the flow had already expired. The packet is dropped
This counter is incremented when the security appliance tries to inject a new or cached packet belonging to a flow that has already expired.It is also incremented when the appliance attempts to send an rst on a tcp flow that has already expired or when a packet returns from IDS blade but the flow had already expired. The packet is dropped
This counter is incremented when the security appliance tries to inject a new or cached packet belonging to a flow that has already expired.It is also incremented when the appliance attempts to send an rst on a tcp flow that has already expired or when a packet returns from IDS blade but the flow had already expired. The packet is dropped
This counter is incremented when the security appliance tries to inject a new or cached packet belonging to a flow that has already expired.It is also incremented when the appliance attempts to send an rst on a tcp flow that has already expired or when a packet returns from IDS blade but the flow had already expired. The packet is dropped
This counter will increment when the ICMP inspection engine fails to allocate an 'App ID' data structure. The structure is used to store the sequence number of the ICMP packet.
This counter will increment when the ICMP code in the ICMP echo request or reply message is non-zero.
No action required if it is an intermittent event. If the cause is an attack, you can deny the host using the ACLs.
This counter will increment when the sequence number in the ICMP echo reply message does not match any ICMP echo message that passed across the appliance earlier on the same connection.
No action required if it is an intermittent event. If the cause is an attack, you can deny the host using the ACLs.
This counter will increment when the appliance is not able to find any established connection related to the frame embedded in the ICMP error message.
No action required if it is an intermittent event. If the cause is an attack, you can deny the host using the ACLs.
This counter will increment when the frame embedded in the ICMP error message does not match the established connection that has been identified when the ICMP connection is created.
No action required if it is an intermittent event. If the cause is an attack, you can deny the host using the ACLs.
This counter will increment when the appliance detects an invalid ICMPv4 or ICMPv6 packet. Examples: Incomplete ICMP header; malformed ICMP Next Header; invalid hop-limit for ICMPv6 NS (neighbor solicitation); etc.
No action required if it is an intermittent event. If the cause is an attack, you can deny the host using the ACLs.
This counter will increment when the appliance detects an invalid frame embedded in the ICMPv6 packet. This check is the same as that on IPv6 packets. Examples: Incomplete IPv6 header; malformed IPv6 Next Header; etc.
This counter will increment when the appliance is not able to find any established connection related to the frame embedded in the ICMPv6 error message.
No action required if it is an intermittent event. If the cause is an attack, you can deny the host using the ACLs.
This counter will increment when the appliance is unable to translate ICMP error messages between IPv6 and IPv4.
No action required if it is an intermittent event. If the cause is an attack, you can deny the host using the ACLs.
This counter will increment when the appliance is unable to translate ICMP messages between IPv6 and IPv4 due to fragmentation. Per RFC-6145, ICMP packet fragments will not be translated.
This counter will increment when the STUN inspection engine fails to allocate an 'Trans ID' data structure. The structure is used to store the transaction id of the STUN packet.
This counter will increment when the transaction id in the STUN successful/error response message does not match any STUN request message that passed across the appliance earlier on the same connection.
No action required if it is an intermittent event. If the cause is an attack, you can deny the host using the ACLs.
No action required if it is an intermittent event. If the cause is an attack, you can deny the host using the ACLs.
This counter will increment when the appliance fails to open a pinhole after a STUN request and successful response message exchange.
This counter will increment when the appliance detects an invalid DNS packet. Examples: A DNS packet with no DNS header; the number of DNS resource records not matching the counter in the header; etc.
This counter will increment when the appliance detects an invalid DNS domain name or label. DNS domain name and label is checked per RFC 1035.
No action required. If the domain name and label check is not desired, disable the protocol-enforcement parameter in the DNS inspection policy-map (in supported releases).
This counter is incremented when the length of the DNS message exceeds the configured maximum allowed value.
No action required. If DNS message length checking is not desired, enable DNS inspection without the 'maximum-length' option, or disable the 'message-length maximum' parameter in the DNS inspection policy-map (in supported releases).
This counter will increment when the DNS inspection engine fails to allocate a data structure to store the identification of the DNS message.
This counter will increment when the identification of the DNS response message does not match any DNS queries that passed across the appliance earlier on the same connection.
No action required if it is an intermittent event. If the cause is an attack, you can deny the host using the ACLs.
This counter will increment when Umbrella was unable to allocate new memory The current packet being processed was dropped.
This counter will increment when a dns response from Umbrella was unable to find pairing client flow to redirect the packet.Packet will be dropped
This counter will increment when the DNS Guard function fails to allocate a data structure to store the identification of the DNS message.
This counter will increment when the identification of the DNS response message does not match any DNS queries that passed across the appliance earlier on the same connection. This counter will increment by the DNS Guard function.
No action required if it is an intermittent event. If the cause is an attack, you can deny the host using the ACLs.
No action required. A capture can be used to figure out which RTP source is sending the incorrect packets and you can deny the host using the ACLs.
The RTP source in your network does not seem to be sending RTP packets conformant with the RFC 1889. The reason for this has to be identified and you can deny the host using ACLs if required.
This counter will increment when the RTP payload type field does not contain an audio payload type when the signalling channel negotiated an audio media type for this RTP secondary connection. The counter increments similarly for the video payload type.
The RTP source in your network is using the audio RTP secondary connection to send video or vice versa. If you wish to prevent this you can deny the host using ACLs.
This counter will increment when the RTP SSRC field in the packet does not match the SSRC which the inspect has been seeing from this RTP source in all the RTP packets.
This could be because the RTP source in your network is rebooting and hence changing the SSRC or it could be because of another host on your network trying to use the opened secondary RTP connections on the firewall to send RTP packets. This should be investigated further to confirm if there is a problem.
This counter will increment when the RTP sequence number in the packet is not in the range expected by the inspect.
No action is required because the inspect tries to recover and start tracking from a new sequence number after a lapse in the sequence numbers from the RTP source.
This counter will increment when the out of sequence packets when the RTP source is being validated exceeds 20. During the probation period, the inspect looks for 5 in-sequence packets to consider the source validated.
No action required. A capture can be used to figure out which RTP source is sending the incorrect packets and you can deny the host using the ACLs.
The RTP source in your network does not seem to be sending RTCP packets conformant with the RFC 1889. The reason for this has to be identified and you can deny the host using ACLs if required.
This counter will increment when the RTCP payload type field does not contain the values 200 to 204.
The RTP source should be validated to see why it is sending payload types outside of the range recommended by the RFC 1889.
This counter is incremented and the packet is dropped as requested by IPS module when the packet matches a signature on the IPS engine.
This counter is incremented and the packet is dropped as requested by CXSC module when the packet matches a signature on the CXSC engine.
This counter is incremented and the packet is dropped as requested by CXSC module when the packet has bad TLV's.
This counter is incremented and the packet is dropped as requested by CXSC module when the packet is malformed.
This counter is incremented and the packet is dropped when CXSC configuration is not found for a particular connection.
This counter is incremented and the packet is dropped when CXSC card is down and fail-close option was used in CXSC action.
This counter is incremented when the security appliance receives a CXSC HA request packet, but could not process it and the packet is dropped.
This could happen occasionally when CXSC does not have the latest ASA HA state, like right after ASA HA state change. If the counter is constantly increasing however, then it can be because CXSC and ASA are out of sync. If that happens, contact Cisco TAC for assistance.
This counter is incremented when the security appliance receives a CXSC packet with invalid messsage header, and the packet is dropped.
This counter is incremented, flow and packet are dropped on ASA as the handle for CX flow has changed in flow duration.
This counter is incremented when the security appliance receives a CXSC packet when in monitor-only mode, and the packet is dropped.
This counter is incremented and the packet is dropped as requested by SFR module when the packet matches a signature on the SFR engine.
This counter is incremented and the packet is dropped as requested by SFR module when the packet has bad TLV's.
This counter is incremented and the packet is dropped as requested by SFR module when the packet is malformed.
This counter is incremented and the packet is dropped when SFR card is down and fail-close option was configured in SFR action.
This counter is incremented and the packet is dropped when SFR configuration is not found for a particular connection.
This counter is incremented when the security appliance receives a SFR HA request packet, but could not process it and the packet is dropped.
This could happen occasionally when SFR does not have the latest ASA HA state, like right after ASA HA state change. If the counter is constantly increasing however, then it can be because SFR and ASA are out of sync. If that happens, contact Cisco TAC for assistance.
This counter is incremented when the security appliance receives a SFR packet with invalid messsage header, and the packet is dropped.
This counter is incremented, flow and packet are dropped on ASA as the handle for SFR flow has changed in flow duration.
This counter is incremented when the security appliance receives a SFR packet when in monitor-only mode, and the packet is dropped.
This event only happens when the system is in the transient state, such as the system is booting, or Snort is in the middle of becoming up or down.
This counter is incremented and the packet is dropped as the Snort module is busy and unable to handle the frame.
This counter is incremented and the packet is dropped when the IPS module license is disabled and the fail-close option was used in IPS inspection.
This counter is incremented and the packet is dropped when IPS configuration is not found for a particular connection.
This counter is incremented and the packet is dropped when IPS card is down and fail-close option was used in IPS inspection.
This counter is incremented when an IPv6 packet, configured to be directed toward IPS SSM, is discarded since the software executing on IPS SSM card does not support IPv6.
This counter will increment when the appliance denies a packet due to a layer-2 ACL. By default, in routed mode the appliance will PERMIT:
The user can also configure ethertype ACL(s) and apply them to an interface to permit other types of L2 traffic.
If your running the appliance/context in transparent mode and your NON-IP packets are dropped by the appliance, you can configure an ethertype ACL and apply the ACL to an access group. Note - the appliance ethertype CLI only supports protocol types and not L2 destination MAC addresses.
This counter will increment when the appliance denies a packet because it fails to locate VXLAN out_tag when applying layer-2 ACL checks.
This only happens under VXLAN based tag-switching use case. Please make sure VXLAN segment-id configuration and tag switching table are correct.
This counter will increment when the appliance denies a packet due to a layer-2 ACL. By default, in routed mode the appliance will PERMIT:
The user can also configure ethertype ACL(s) and apply them to an interface to permit other types of L2 traffic.
If your running the appliance/context in transparent mode and your NON-IP packets are dropped by the appliance, you can configure an ethertype ACL and apply the ACL to an access group. Note - the appliance ethertype CLI only supports protocol types and not L2 destination MAC addresses.
Either received data from client while waiting for SYNACK from server or received a packet which cannot be handled in a particular state of TCP intercept.
If this drop is causing the connection to fail, please have a sniffer trace of the client and server side of the connection while reporting the issue. The box could be under attack and the sniffer traces or capture would help narrowing down the culprit.
A packet has arrived that matches a multicast flow, but the multicast service is no longer enabled, or was re-enabled after the flow was built.
A multicast entry change has been detected after a packet was punted to the CP, and the NP can no longer forward the packet since no entry is present.
This counter is incremented when the appliance fails to allocate memory while reassembling a chain of fragmented packets into a single packet. All the fragment packets in the chain are dropped.
For software versions without customizable mac-address support, use the "global" or "static" command to specify the IPv4 addresses that belong to each context interface. For software versions with customizable mac-address support, enable "mac-address auto" in system context. Alternatively, configure unique MAC addresses for each context interfaces residing over a shared interface with "mac-address" command under each context interface submode.
The message could occur from user interface command to remove connection in an device that is actively processing packet. Otherwise, investigate flow drop counter. This message may occur if the flow are forced dropped from error.
This counter will increment for each packet received on an interface that is shutdown via the 'shutdown' interface sub-mode command. For ingress traffic, the packet is dropped after security context classification and if the interface associated with the context is shut down. For egress traffic, the packet is dropped when the egress interface is shut down.
This counter will increment when the appliance detects an invalid length of the Layer 7 payload in the packet. Currently, it counts the drops by the DNS Guard function only. Example: Incomplete DNS header.
This counter is incremented and the packet is dropped when packets are sent from one context of the appliance to another context through a shared interface and there is no buffer space in loopback queue.
This counter will increment when the appliance receives a packet which is NOT IPv4, IPv6 or ARP and the appliance/context is configured for ROUTED mode. In normal operation such packets should be dropped by the default L2 ACL configuration.
This counter will increment when the appliance/context is configured for transparent and source interface of a known L2 MAC address is detected on a different interface.
This indicates that a host has been moved from one interface (i.e. LAN segment) to another. This condition is normal while in transparent mode if the host has in fact been moved. However, if the host move toggles back and forth between interfaces, a network loop may be present.
This counter is incremented when the security appliance receives an IP packet in transparent mode and has no management IP address defined. The packet is dropped.
This counter is incremented when the security appliance receives a tunnel IP packet and an error is encountered during the passenger IP packet processing.The packet is dropped.
This counter will increment when a packet is received which has a source IP address that matches a host in the shun database.
This counter is incremented when the maximum number of connections for a context or the system has been reached and a new connection is attempted.
The device administrator can use the commands 'show resource usage' and 'show resource usage system' to view context and system resource limits and 'Denied' counts and adjust resource limits if desired.
This counter is incremented when the maximum connection rate for a context or the system has been reached and a new connection is attempted.
The device administrator can use the commands 'show resource usage' and 'show resource usage system' to view context and system resource limits and 'Denied' counts and adjust resource limits if desired.
If a socket is abruptly closed, by the user or software, then any pending packets in the pipeline for that socket are also dropped. This counter is incremented for each packet in the pipeline that is dropped.
It is common to see this counter increment as part of normal operation. However, if the counter is rapidly incrementing and there is a major malfunction of socket-based applications, then this may be caused by a software defect. Contact the Cisco TAC to investigate the issue further.
This counter is incremented when the Port Forwarding application's internal queue is full and it receives another packet for transmission.
This counter only applies to the ASA 5500 series adaptive security appliance. It is incremented when the security appliance receives a packet from the internal data plane interface but could not find the proper driver to parse it.
The data plane driver is dynamically registered depending on the type of SSM installed in the system. So this could happen if data plane packets arrive before the security appliance is fully initialized. This counter is usually 0. You should not be concerned if there are a few drops. However, if this counter keeps rising when system is up and running, it may indicate a problem. Please contact Cisco Technical Assistance Center (TAC) if you suspect it affects the normal operation of your the security appliance.
This counter only applies to the ASA 5500 series adaptive security appliance. It is incremented when the security appliance receives an ASA SSM Dataplane Protocol (ASDP) packet from the internal data plane interface, but the driver encountered a problem when parsing the packet. ASDP is a protocol used by the security appliance to communicate with certain types of SSMs, like the CSC-SSM. This could happen for various reasons, for example ASDP protocol version is not compatible between the security appliance and SSM, in which case the card manager process in the control plane issues system messages and CLI warnings to inform you of the proper version of images that need to be installed; the ASDP packet belongs to a connection that has already been terminated on the security appliance; the security appliance has switched to the standby state (if failover is enable) in which case it can no longer pass traffic; or any unexpected value when parsing the ASDP header and payload.
The counter is usually 0 or a very small number. But user should not be concerned if the counter slowly increases over the time, especially when there has been a failover, or you have manually cleared connections on the security appliance via CLI. If the counter increases drastically during normal operation, please contact Cisco Technical Assistance Center (TAC).
This counter only applies to the ASA 5500 series adaptive security appliance. It is incremented when the application running on the SSM requests the security appliance to drop a packet.
More information could be obtained by querying the incident report or system messages generated by the SSM itself. Please consult the documentation that comes with your SSM for instructions.
This counter only applies to the ASA 5500 series adaptive security appliance. It is incremented when a packet to be inspected by the SSM is dropped because the SSM has become unavailable. Some examples of this are: software or hardware failure, software or signature upgrade, or the module being shut down.
The card manager process running in the security appliance control plane would have issued system messages and CLI warning to inform you of the failure. Please consult the documentation that comes with the SSM to trouble shoot the SSM failure. Contact Cisco Technical Assistance Center (TAC) if needed.
This counter is incremented when a packet is returned from the Cache Engine and the security appliance does not find a route for the original source of the packet.
This counter is incremented when the security appliance tries to redirect a packet and does not find a route to the Cache Engine.
This counter is incremented and packet is dropped when the appliance receives a TCP SYN packet attempting to establish a TELNET session to the appliance and that packet was received on the least secure interface.
To establish a TELNET session to the appliance via the least secure interface, first establish an IPSec tunnel to that interface and then connect the TELNET session over that tunnel.
These packets could indicate malicious activity, or could be the result of a misconfigured IPv6 host. Use the packet capture feature to capture type asp packets, and use the source MAC address to identify the source.
This counter is incremented and packet is dropped when the appliance receives a IPv6 packet but extension header could not be inspected due to memory allocation failed.
This counter is incremented and packet is dropped when the appliance receives a IPv6 packet with bad extension header.
Check 'verify-header type' of 'parameters' in 'policy-map type ipv6'. Remove 'verify-header type' if the header conformance can be skipped.
This counter is incremented and packet is dropped when the appliance receives a IPv6 packet with extension headers not in proper order.
Check 'verify-header order' of 'parameters' in 'policy-map type ipv6'. Remove 'verify-header order' if the header order can be arbitrary.
This counter is incremented and packet is dropped when the appliance receives a IPv6 packet with mobility extension header which is denied by the user configuration rule.
Check action of 'match header mobility' in 'policy-map type ipv6'. Remove action 'drop' if mobility should be allowed.
This counter is incremented and packet is dropped when the appliance receives a IPv6 packet with mobility type extension header which is denied by the user configuration rule.
Check action of 'match header mobility type' in 'policy-map type ipv6'. Remove action 'drop' if mobility should be allowed.
This counter is incremented and packet is dropped when the appliance receives a IPv6 packet with fragmentation extension header which is denied by the user configuration rule.
Check action of 'match header fragmentation' in 'policy-map type ipv6'. Remove action 'drop' if fragmentation should be allowed.
This counter is incremented and packet is dropped when the appliance receives a IPv6 packet with routing type extension header which is denied by the user configuration rule.
Check action of 'match header routing-type' in 'policy-map type ipv6'. Remove action 'drop' if routing-type should be allowed.
This counter is incremented and packet is dropped when the appliance receives a IPv6 packet with fragmentation extension header which is denied by the user configuration rule.
Check action of 'match header fragmentation' in 'policy-map type ipv6'. Remove action 'drop' if fragmentation should be allowed.
This counter is incremented and packet is dropped when the appliance receives a IPv6 packet with destination-option extension header which is denied by the user configuration rule.
Check action of 'match header destination-option' in 'policy-map type ipv6'. Remove action 'drop' if destination-option should be allowed.
This counter is incremented and packet is dropped when the appliance receives a IPv6 packet with hop-by-hop extension header which is denied by the user configuration rule.
Check action of 'match header hop-by-hop' in 'policy-map type ipv6'. Remove action 'drop' if hop-by-hop should be allowed.
This counter is incremented and packet is dropped when the appliance receives a IPv6 packet with ESP extension header which is denied by the user configuration rule.
Check action of 'match header esp' in 'policy-map type ipv6'. Remove action 'drop' if ESP should be allowed.
This counter is incremented and packet is dropped when the appliance receives a IPv6 packet with AH extension header which is denied by the user configuration rule.
Check action of 'match header ah' in 'policy-map type ipv6'. Remove action 'drop' if AH should be allowed.
This counter is incremented when the data path channel has been closed before the packet attempts to be sent out through this channel. Recommendation:
It is normal in multi-processor system when one processor closes the channel (e.g., via CLI), and another processor tries to send a packet through the channel.
This counter is incremented when the packet dispatch module finds an error when decoding the frame. An example is an unsupported packet frame. Recommendation:
This counter is incremented when a CP event queue enqueue attempt has failed due to queue length exceeded. This queue is used by the data-path to punt packets to the control-point for additional processing. This condition is only possible in a multi-processor enviroment. The module that attempted to enqueue the packet may issue it's own packet specific drop in response to this error. Recommendation:
While this error does indicate a failure to completely process a packet, it may not adversely affect the connection. If the condition persists or connections are adversely affected contact the Cisco Technical Assistance Center (TAC). Syslogs:
This counter is incremented when a CP syslog event queue enqueue attempt has failed due to queue length exceeded. This queue is used by the data-path to punt logging events to the control-point when logging destinations other than to a UDP server are configured. This condition is only possible in a multi-processor environment. Recommendation:
While this error does indicate a failure to completely process a logging event, logging to UDP servers should not be affected. If the condition persists consider lowering the logging level and/or removing logging destinations or contact the Cisco Technical Assistance Center (TAC). Syslogs:
This counter is incremented and the packet is dropped when the appliance could not allocate a core local block to process the packet that was received by the interface driver.
This may be due to packets being queued for later processing or a block leak. Core local blocks may also not be available if they are not replenished on time by the free resource rebalancing logic. Please use "show blocks core" to further diagnose the problem.
There are 32K load balancer queues that a packet could be hashed to. Each queue has a limit of 1000 packets. When more packets are attempted, tail drop occurs and this counter is incremented.
If this happens excessively, find out which queues are affected and the connections hashing to that queue. Send this information to development
Each async lock working queue has a limit of 1000. When more SIP packets are attempted to be dispatch to the work queue, packet will be dropped.
Only SIP traffic may be dropped. When SIP packets have the same parent lock and they can be queued into the same async lock queue, thus may result into blocks depletion, becasue only single core is handling all the media. If a SIP packet attempts to be queued when the size of the async lock queue exceeds the limit, the packet will be dropped.
This traffic does not use a security-profile. Traffic through ASA 1000V is expected to use a security-profile configured on Nexus 1000V.
Check the port-profile configuration on the Nexus 1000V with "show port-profile" and verify that a security-profile is configured for each port-profile redirecting traffic to ASA 1000V, and that security-profile names match between Nexus 1000V and ASA 1000V. Verify that security-profiles are associated with the inside interface using "service-interface security-profile all <inside_interface_name>" on ASA 1000V. Use "show vsn port" on Nexus 1000V and "show vsn security-profile" on ASA 1000V to verify that security-profiles have matching ID values on both devices.
Check the port-profile configuration on the Nexus 1000V with "show port-profile" and verify that a security-profile is configured for each port-profile redirecting traffic to ASA 1000V, and that security-profile names match between Nexus 1000V and ASA 1000V. Verify that security-profiles are associated with the inside interface using "service-interface security-profile all <inside_interface_name>" on ASA 1000V. Use "show vsn port" on Nexus 1000V and "show vsn security-profile" on ASA 1000V to verify that security-profiles have matching ID values on both devices.
This counter is incremented and the packet is dropped when packets are sent from one context of the appliance to another context through a shared interface and the loopback queue has failed to acquire a lock.
This condition should never be encountered during normal operation and may indicate a software problem with the appliance. Contact the Cisco Technical Assistance Center (TAC) if this error occurs.
This counter is incremented and the packet is dropped when packets are sent from one context of the appliance to another context through a shared interface, and the output interface is not found by the loopback queue.
This condition should never be encountered during normal operation and may indicate a software problem with the appliance. Contact the Cisco Technical Assistance Center (TAC) if this error occurs.
This counter is incremented and the packet is dropped when a packet is sent from one context of the appliance to another context through a shared interface, but this packet has exceeded the number of times it is allowed to queue to the loopback queue.
Check the context configuration for each context. The packet is entering a loop in the context configurations so that it is stuck between contexts, and is repeatedly put into the loopback queue.
This counter will increment when the appliance attempts to send a message indicating that a new SA is needed to a rate-limited control point service routine and the rate limit (per/second) is now being exceeded. The current rate is one message every two seconds.
This counter will increment when the appliance attempts to send a message indicating that a new SA is needed to a rate-limited control point service routine and the global rate limit (per/second) is now being exceeded. The current rate is ten message per second.
In case of shared interface, we need to loopback multicast and broadcast traffic. When system resource 'packet block extension memory' limitation is reached, this counter will be incremented, the packet will be droppped and the packet will not be replicated to other contexts.
This counter is incremented when the security appliance finds scansafe cloud down. The packet is dropped and the connection isclosed.
This counter is incremented when the scansafe public key is not configured. The packet is dropped and the connection isclosed.
This counter is incremented when the scansafe licnese key is not configured. The packet is dropped and the connection isclosed.
This counter is incremented when the base64 encoding of user and group name is failed. The packet is dropped and connection is closed.
This counter is incremented when the encryption of scansafe header is failed. The packet is dropped and connection is closed.
This counter is incremented when we get a new connection and the maximum allowed concurrent scansafe connection for the platform is already reached. The packet is dropped and connection is closed.
This counter is incremented when duplicate connection with the same source ip address and port. This packet will be dropped and connection will be closed.
This condition should never be encountered during normal operation and may indicate a software problem with the appliance. Contact the Cisco Technical Assistance Center (TAC) if this error occurs.
Check the NAT and routing policies configured on ASA 1000V. Use ASA 1000V "packet-tracer" command to determine which security-profiles are used based on the NAT and routing policies configured. Use "show running-config service-interface" to display the association between the physical interfaces and the configured security-profiles.
Check Nexus 1000V and verify that there are sufficient ASA 1000V licenses installed to support all ASA 1000V virtual machines in use. Use "show license" to check the available licenses for ASA 1000V and use "show license usage" to check the status of them.
This counter is incremented when the security appliance receives a invalid CMD packet. The packet is dropped.
This counter is incremented when the security appliance receives a CMD packet on an interface not configured to recieve one. The packet is dropped.
A Cluster data packet was received over CCL and full flow is built on a new owner. This packet is no longer needed.
A Cluster data packet was received over CCL on a backup unit, when it should have been received on the owner+director unit.
A Cluster packet was received on director, stub flow was converted to full flow. Drop this packet and wait for retransmission.
A Cluster data packet was received over CCL and no matching flow is found, and unit has unknown role.
A Cluster data packet was received over CCL and a matching stub flow found, but unit has unknown role.
Cluster may be oversubscribed because cluster is under high pressure to send out cluster logic update (CLU) message.
This behavior is expected as cluster is oversubscribed and is under high pressure to send out cluster logic update (CLU) message. Please avoid oversubscribing the cluster.
A multicast routing packet was received on a L3 cluster interface when the unit was a slave. Only a master unit is permitted to process these packets.
A multicast data packet was received on a L3 cluster interface when the unit was not an elected owner unit. Only an elected owner unit is permitted to process these packets.
This counter is informational and the behavior expected. The packet is processed by one elected owner unit.
If NAT is not desired, disable "nat-control". Otherwise, use the "static", "nat" or "global" command to configure NAT policy for the dropped flow. For dynamic NAT, ensure that each "nat" command is paired with at least one "global" command. Use "show nat" and "debug pix process" to verify NAT rules.
When not on the same interface as the host undergoing NAT, use the mapped address instead of the real address to connect to the host. Also, enable the appropriate inspect command if the application embeds IP address.
No pre-existing xlate found for a connection with a destination matching a mapped address in a PAT pool.
There is a mismatch between port block state and configuration across cluster. This usually happens when a dynamic PAT rule is converted from "block-allocation" to regular or vice-versa with active translations.
Please execute the following recommended steps - 1. Remove the current policy which resulted in this inconsistent state 2. Clear the active translations established by the removed policy as "cluster exec clear xlate global <ip1[-ip2]>" 3. Make sure there are no active translations using previous global IPs, through "cluster exec show xlate global <ip1[-ip2]>" 4. Add back the policy with needed pat-pool options.
A multicast data packet was received on a L3 cluster interface when it is from a cluster peer unit corresponding interface. This is a packet flooded back from L3 subnet.
This counter is informational and the behavior expected. The packet has been forwarded out of the cluster and should be ignored by cluster.
Director is trying to create a stub flow but failed due to resource limitation. The resource limit may be either:
- Observe if connection count reaches the system connection limit with the command "show resource usage".
Director applied early security check has failed due to ACL, WCCP redirect, TCP-intercept or IP option.
Cluster director NAT action has changed due to NAT policy change, update or expiration before queued ccl data packet can be processed.Recommendation:
Cluster director has processed a previously queued packet with invalid ingress and/or egress interface. This is a result of interface removal (through CLI) before the packet can be processed.
Cluster data interface on slave unit is not ready (some data interfaces are in different state from the master). For a L3 interface that is not management-only, before the data interface is ready the slave cannot own any connection on this L3 interface. Packets must be owned by the slave are dropped. From the box packets are also dropped before slave's data interface becomes ready. This drop will not occur after slave's data interface is ready and the slave fully joins the cluster.
Cluster master has failed to send NAT pool update to slave unit. This drop will increase if system resources is low.
Cluster member received a NAT untranslate packet from peer. However this member does not own the NAT address pool the packet belongs to.
Thsi counter is a temporal condition after a cluster member failure. However, if this counter is incremented continuously, it could be an internal software error. Contact Cisco Systems in such case.Syslogs:
The ASAv is not licensed. All data traffic traversing the appliance will be dropped until the ASAv is licensed.
Check the platform license state with "show activation-key" and install the appropriate ASAv platform license.
The sender information in the transport header indicates that the sender is myself, which could happen if two clusters (with overlapping IDs) exist on the same network segment.
A failure either when forwarding first fragment to flow director or fragment chain reinsert failure.
The fragment is not formatted correctly and cannot be processed or forwarding to the Fragment Owner failed.
This reason is given for dropping a packet when the transactional commit mode is used and the initial rule transaction compiling is still in progress. All through-the-box traffic is dropped when the ASA is in this state.
This is a temporal condition that happens once during the system initialization or the security context initialization. The duration of this condition depends on the number of rules, such as ACLs or NAT rules, in the configuration.
This reason is given for dropping a packet when the device is in HA mode and is currently not in active state and a multicast packet is received. As the HA device can only process the multicast in the active state, the received packet will be dropped.
This counter will increment when there is not enough space before the packet data to prepend a header in order to put the packet onto the network.
This counter is incremented and the packet is dropped when tcp proxy couldn't pass the packets for inspection.
This counter is incremented and the packet is dropped when GTP inspection found validation or internal errors, or performed policy drop.
This counter is incremented and the packet is dropped when the TCP proxy encounters a error during three way handshake.
This counter is incremented and the packet is dropped when the TCP proxy encounters a error during mixed mode operation, transitioning from light weight TCP proxy to full mode TCP proxy.
This counter is incremented and the light weight proxy tx queue is cleared when the TCP proxy is transitioning from light weight TCP proxy to full TCP proxy.We enqueue a FIN segment when inspection is in progress When we trigger full proxy, this queue should be cleared.
This counter is incremented and the packet is dropped when the TCP proxyreceives out of order packets for processing in lightweight mode.
This counter is incremented and the packet is dropped when tcp proxy received a retransmit packet that is still being inspected.
This counter is incremented and the packet is dropped when a flow to be inspected by the Snort is missing relevant info to capture Snort data.
This counter is incremented and the packet is dropped when tcp proxy receives a packet while trying to bypass Full Proxy and proxy layer has reached its enqueue limit.
This counter is incremented and the packet is dropped when tcp proxy received a packet for a non-existant flow.
This counter is incremented and the packet is dropped when the tcp proxy was unable to copy a packet since it was unable to allocate a new one.
This counter is incremented and the packet is dropped when the tcp proxy was unable to copy L2 header to a packet in Full Proxy mode.
This counter is incremented and the packet is dropped when there was no header room left for L2 header of a packet in Full Proxy mode.
This counter is incremented and the packet is dropped when the L2 header of a packet was not initialized in Full Proxy mode.
This counter is incremented and the packet is dropped when the RST/FIN with data packet received with invalid checksum.
This counter is incremented and the packet dropped when datapath punts packets to inspectors and the no. of packets queued exceeded the maximum limit.
This counter is incremented and the packet dropped if there is a mismatch in monitor-only mode config and the AFBP header flag.
This counter is incremented after packet processing is complete in inline-tap and passive modes, the packet is dropped after this.
This counter is incremented and the packet dropped when datapath buffers packets to avoid out-of-order on fast-forwarded flows and the no. of packets queued exceeded the maximum limit.
This counter is incremented and the packet is dropped as the next hop configured on pbr is of connected IP.
This counter is incremented when a packet is checked against an access-list and the number of access-list object-groups that matched the packet exceeds 10000. If this occurs, the packet is dropped. Access-list checks can negatively impact the performance of the device when a packet matches an excessive number of object-groups when object-group-search access-control feature is enabled.
Reconfigure the access-list and object-group configuration to ensure that traffic will not match an excess number of object-groups. Usually this problem is triggered by a large number of overlapping or duplicated objects. Examine the traffic being dropped with 'capture asp type asp-drop ogs-match-limit-exceeded', then 'show capture asp'.
This counter is incremented when any non IP packet is received on Memif for policy lookup. Non IP packets are dropped in that case.
This counter is incremented when any packet is received on Memif not tagged for policy lookup. Such packets are dropped in that case.
This counter is incremented and the packet is dropped as requested by the captive portal preprocessor.
This counter is incremented and the packet is dropped as requested by the defragmentation preprocessor.
This counter is incremented and the packet is dropped as requested by the snort response preprocessor.
This counter is incremented and the packet is dropped as requested by the x-link2state preprocessor.
This counter is incremented and the packet is dropped as requested by the back orifice preprocessor.
Dynamic PAT pool owner received a NAT untranslate packet from peer. However it matches a director stub flow.
This counter is a temporal condition after a cluster member failure. However, if this counter is incremented continuously, there could be a timing issue that caused the error. Contact Cisco Systems in such case.Syslogs:
Dynamic PAT pool owner received a NAT untranslate packet from peer. However it matches a backup stub flow.
This counter is a temporal condition after a cluster member failure. However, if this counter is incremented continuously, there could be a timing issue that caused the error. Contact Cisco Systems in such case.Syslogs:
This counter is incremented and the packet dropped when the security appliance receives a packet with too many layers of VLAN tags.
This counter is incremented when the appliance fails to reassemble the fragmented IP packets. All the fragment packets in the chain are dropped.
This counter is incremented when we fail to create a cluster stub flow in the peer receiving a forwarded VPN decoded packet, because there is already a full flow.
This counter is incremented when we fail to create a cluster stub flow in the peer receiving a forwarded VPN decoded packet.
This counter is incremented when a cluster peer tries to encrypt a packet but fails to get the VPN context.
This counter is incremented when a cluster node fails to find the onwer for the connection from VPN director
This counter is incremented and the packet is dropped when SPI consistency checks fail indicating the packet might have been altered in transit.
Check the syslog to get more information about the origin of packet. This situation can be normal and transient. If the drops persist, call TAC to investigate further.
This counter is incremented and the packet is dropped when the SPI received in the incoming packet is considered expired.
Check the syslog to get more information about the origin of packet. If this is a valid peer connection, this may be the result of a very long network delay that should be eliminated. If the drops persist, call TAC to investigate further.
This counter is incremented and the packet is dropped as verdict is invalid and cannot be acted up on.
This counter is incremented when there is an error encountered during reassembling of packets received from snort.
This counter is incremented and the packet is dropped when NLP tries to send a fragmented packet with invalid size through failover link.
This counter is incremented and the packet is dropped when NLP tries to send or receive a packet however failover link lu status is down.
This counter is incremented and the packet is dropped when NLP failed to send packet through failover link.
A packet with an address that matches a MAP (Mapping of Address and Port) domain Basic Mapping Rule has inconsistent encoding or the port number used is not within the allotted range.
フローのドロップ理由
This counter will increment when the appliance receives a packet associated with an established flow whose IPSec security association is in the process of being deleted.
This counter will increment when the appliance receives an IPSec ESP packet, IPSec NAT-T ESP packet or an IPSec over UDP ESP packet encapsulated in an IP version 6 header. The appliance does not currently support any IPSec sessions encapsulated in IP version 6.
This counter will increment when the appliance receives a packet matching an entry in the security policy database (i.e. crypto map) but the security association is in the process of being negotiated; its not complete yet.
This counter will also increment when the appliance receives a packet matching an entry in the security policy database but the security association has been or is in the process of being deleted. The difference between this indication and the 'Tunnel has been torn down' indication is that the 'Tunnel has been torn down' indication is for established flows.
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.
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.
This counter is incremented when the appliance is unable to create a VPN handle because the VPN handle already exists.
It is possible to see this counter increment as part of normal operation. However, if the counter is rapidly incrementing and there is a major malfunction of vpn-based applications, then this may be caused by a software defect. Use the following commands to gather more information about this counter and contact the Cisco TAC to investigate the issue further.
This counter is incremented when a datagram hits an encrypt, or decrypt operation, and no VPN handle is found for the flow the datagram is on.
It is possible to see this counter increment as part of normal operation. However, if the counter is rapidly incrementing and there is a major malfunction of vpn-based applications, then this may be caused by a software defect. Use the following commands to gather more information about this counter and contact the Cisco TAC to investigate the issue further.
This counter will increment when the appliance receives a packet which should have been encrypted but was not. The packet matched the inner header security policy check of a configured and established IPSec connection on the appliance but was received unencrypted. This is a security issue.
This counter will increment when the security appliance receives a packet which should have been encrypted but was not. The packet matched the inner header security policy check of a configured and established SVC connection on the security appliance but was received unencrypted. This is a security issue.
This counter is incremented for each new SVC socket connection that is disconnected when the active unit is transitioning into standby state as part of a failover transition.
None. This is part of a normal cleanup of a SVC connection when the current device is transitioning from active to standby. Existing SVC connections on the device are no longer valid and need to be removed.
None. This may indicate that users are having difficulty maintaining connections to the ASA. Users should evaluate the quality of their home network and Internet connection.
This counter is incremented when an IPSec packet is received with an inner IP header that does not match the configured policy for the tunnel.
Verify that the crypto ACLs for the tunnel are correct and that all acceptable packets are included in the tunnel identity. Verify that the box is not under attack if this message is repeatedly seen.
This counter will increment when the security appliance receives a packet that requires encryption or decryption, and the ASP VPN context required to perform the operation is no longer valid.
When a packet is decrypted the inner packet is examined against the crypto map configuration. If the packet matches a different crypto map entry than the one it was received on it will be dropped and this counter will increment. A common cause for this is two crypto map entries containing similar/overlapping address spaces.
Check your VPN configuration for overlapping networks. Verify the order of your crypto maps and use of 'deny' rules in ACLs.
This condition should never be encountered during normal operation and may indicate a software problem with the appliance. Contact the Cisco Technical Assistance Center (TAC) if this error occurs.
When VPN policies change, flows that no longer match those policies are freed as packets arrive for those flows.
A VPN flow creation was attempted before its decryption policy was fully initialized. This is a transient condition and will be resolved once the decryption policy completes its installation.
It is possible to see this counter increment as part of normal operation. However, if the counter is rapidly incrementing and there is a traffic disruption, then this may be caused by a misconfiguration or a software defect. Use the following commands to gather more information about this counter and contact the Cisco TAC to investigate the issue further.
It is possible to see this counter increment as part of normal operation. However, if the counter is rapidly incrementing and there is a traffic disruption, then this may be caused by a misconfiguration or a software defect. Use the following commands to gather more information about this counter and contact the Cisco TAC to investigate the issue further.
It is possible to see this counter increment as part of normal operation. However, if the counter is rapidly incrementing and there is a traffic disruption, then this may be caused by a misconfiguration or a software defect. Use the following commands to gather more information about this counter and contact the Cisco TAC to investigate the issue further.
This counter is incremented when the appliance is unable to create a flow because of insufficient memory.
Verify that the box is not under attack by checking the current connections. Also verify if the configured timeout values are too large resulting in idle flows residing in memory longer. Check the free memory available by issuing 'show memory'. If free memory is low, issue the command 'show processes memory' to determine which processes are utilizing most of the memory.
When the parent flow of a subordinating flow is closed, the subordinating flow is also closed. For example, an FTP data flow (subordinating flow) will be closed with this specific reason when its control flow (parent flow) is terminated. This reason is also given when a secondary flow (pin-hole) is closed by its controlling application. For example, when the BYE messaged is received, the SIP inspection engine (controlling application) will close the corresponding SIP RTP flows (secondary flow).
This reason is given for closing a flow due to an error detected during application inspection. For example, if an error is detected during inspecting an H323 message, the corresponding H323 flow is closed with this reason.
If the appliance is running stateful failover, then this counter should increment for every replicated connection that is torn down on the standby appliance.
If a through-the-box packet arrives at an appliance or context is in a Standby state, and a flow is created, the packet is dropped and the flow removed. This counter will increment each time a flow is removed in this manner.
This counter should never be incrementing on the Active appliance or context. However, it is normal to see it increment on the Standby appliance or context.
If appliance is processing VPN traffic, then this counter could be constantly increasing on the standby unit because of the flow could be replicated before the IKE SA info. No action is required in this case. If the appliance is not processing VPN traffic, then this indicate a software detect, turn on the debug: "debug fover fail" on the standby unit, collect the debug output, and report the problem to Cisco TAC.
This reason is given for closing a flow due to the following conditions: 1) when U-turn traffic is present on the flow, and, 2) 'same-security-traffic permit intra-interface' is not configured.
To allow U-turn traffic on an interface, configure the interface with 'same-security-traffic permit intra-interface'.
This counter is incremented when a drop rule is hit by the packet and flow creation is denied. This rule could be a default rule created when the box comes up, when various features are turned on or off, when an acl is applied to interface or any other feature etc. Apart from default rule drops, a flow could be denied because of:
Observe if one of syslogs related to packet drop are fired. Flow drop results in the corresponding packet-drop that would fire requisite syslog.
This counter is incremented when a drop rule is hit by the packet during reclassification of ACL rules.
Observe if one of syslogs related to packet drop are fired. Flow drop results in the corresponding packet-drop that would fire requisite syslog.
This counter is incremented to report that the appliance opened a secondary flow, but no packets passed through this flow within the timeout interval, and hence it was removed. An example of a secondary flow is the FTP data channel that is created after successful negotiation on the FTP control channel.
This counter is incremented when a flow is closed because of the expiration of it's inactivity timer.
This reason is given for closing a flow when the connection limit has been exceeded. The connection limit is configured via the 'set connection conn-max' action command.
If these are valid session which take longer to establish a connection increase the embryonic timeout.
This reason is given for closing an outbound flow (from a low-security interface to a same- or high-security interface) when a TCP reset is received on the flow.
This reason is given for closing an inbound flow (from a high-security interface to low-security interface) when a TCP reset is received on the flow.
A flow was recursively freed. This reason applies to pair flows, multicast slave flows, and syslog flows to prevent syslogs being issued for each of these subordinate flows.
SYN retransmission timeout after trying three times, once every second. Server unreachable, tearing down connection.
This reason is given for closing a TCP flow when check-retranmission feature is enabled and the TCP endpoint sent a retranmission with different data from the original packet.
The TCP endpoint maybe attacking by sending different data in TCP retransmits. Please use the packet capture feature to learn more about the origin of the packet.
This reason is given for closing a TCP flow when window size advertized by TCP endpoint is drastically changed without accepting that much data.
SYN packet could be invalid for number of reasons, like invalid checksum, invalid TCP header. Please use the packet capture feature to understand why the SYN packet is invalid. If you would like to allow these connection use tcp-map configurations to bypass checks.
This counter is incremented and the flow is dropped when sctp INIT chunk contains 0 value initiate tag.
This counter is incremented and the flow is dropped when sctp INIT ACK chunk contains 0 value initiate tag.
This counter is incremented and the packet is dropped when sctp INIT chunk contains 0 value inbound/outbound stream count.
This counter is incremented and the flow is dropped when sctp INIT chunk timeout count reaches limit.
This drop can happen in a scenarios like when the receiver of INIT chunk is not responding INIT ACK or there could be redundant path between client and server where INIT goes in one path and INIT ACK comes in another path. If this error occurs in large numbers, please use packet capture feature to help isolate the issue.
This counter is incremented and the flow is dropped when sctp cookie state (after received INIT ACK or COOKIE ECHO) timeout count reaches limit.
This counter is incremented and the packet is dropped when sctp INIT ACK chunk contains 0 value inbound/outbound stream count.
A packet has arrived that matches a multicast flow, but the multicast service is no longer enabled, or was re-enabled after the flow was built.
The multicast entry has been deleted so the flow is being cleaned up, but the packet will be reinjected into the data path.
TCP intercept would teardown a connection if this is the first SYN, a connection is created for the SYN, and TCP intercept replied with a SYN cookie, or after seeing a valid ACK from client, when TCP intercept sends a SYN to server, server replies with a RST.
TCP intercept normally does not create a connection for first SYN, except when there are nailed rules or the packet comes over a VPN tunnel or the next hop gateway address to reach the client is not resolved. So for the first SYN this indicates that a connection got created. When TCP intercept receives a RST from server, its likely the corresponding port is closed on the server.
If removing the flow is not the desired outcome of matching this signature, then remove the reset action from the "ip audit" command.
This reason is given for terminating a flow since CXSC card is down and fail-close option was used with CXSC action.
This reason is given for terminating a flow since SFR card is down and fail-close option was used with SFR action.
This reason is given for terminating a flow since IPS card is down and fail-close option was used with IPS inspection.
This reason is given for terminating a flow when the IPS module license is disabled and the fail-close option was used in IPS inspection.
This counter is incremented when a packet is punted to the exception-path for processing by one of the enhanced services such as inspect, aaa etc and the servicing routine, having detected a violation in the traffic flowing on the flow, requests that the flow be dropped. The flow is immediately dropped.
Please watch for syslogs fired by servicing routine for more information. Flow drop terminates the corresponding connection.
This counter will increment when a packet is received which has a source IP address that matches a host in the shun database. When a shun command is applied, it will be incremented for each existing flow that matches the shun command.
If NAT is not desired, disable "nat-control". Otherwise, use the "static", "nat" or "global" command to configure NAT policy for the dropped flow. For dynamic NAT, ensure that each "nat" command is paired with at least one "global" command. Use "show nat" and "debug pix process" to verify NAT rules.
When not on the same interface as the host undergoing NAT, use the mapped address instead of the real address to connect to the host. Also, enable the appropriate inspect command if the application embeds IP address.
This counter will increment when the appliance fails to enable protocol inspection carried out by the NP for the connection. The cause could be memory allocation failure, or for ICMP error message, the appliance not being able to find any established connection related to the frame embedded in the ICMP error message.
Check system memory usage. For ICMP error message, if the cause is an attack, you can deny the host using the ACLs.
This counter will increment when the security appliance fails to allocate a run-time inspection data structure upon connection creation. The connection will be dropped.
This error condition is caused when the security appliance runs out of system memory. Please check the current available free memory by executing the "show memory" command.
This counter is incremented when a reclaimable flow is removed to make room for a new flow. This occurs only when the number of flows through the appliance equals the maximum number permitted by the software imposed limit, and a new flow request is received. When this occurs, if the number of reclaimable flows exceeds the number of VPN tunnels permitted by the appliance, then the oldest reclaimable flow is removed to make room for the new flow. All flows except the following are deemed to be reclaimable:
No action is required if this counter is incrementing slowly. If this counter is incrementing rapidly, it could mean that the appliance is under attack and the appliance is spending more time reclaiming and rebuilding flows.
This counter is incremented when the maximum number of xlates for a context or the system has been reached and a new connection is attempted.
The device administrator can use the commands 'show resource usage' and 'show resource usage system' to view context and system resource limits and 'Denied' counts and adjust resource limits if desired.
This counter is incremented when the maximum number of hosts for a context or the system has been reached and a new connection is attempted.
The device administrator can use the commands 'show resource usage' and 'show resource usage system' to view context and system resource limits and 'Denied' counts and adjust resource limits if desired.
This counter is incremented when the maximum inspection rate for a context or the system has been reached and a new connection is attempted.
The device administrator can use the commands 'show resource usage' and 'show resource usage system' to view context and system resource limits and 'Denied' counts and adjust resource limits if desired.
A TCP connect socket clashes with an existing listen connection. This is an internal system error. Contact TAC.
This counter only applies to the ASA 5500 series adaptive security appliance. It is incremented when the application running on the SSM requests the security appliance to terminate a connection.
You can obtain more information by querying the incident report or system messages generated by the SSM itself. Please consult the documentation that comes with comes with the SSM for instructions.
This counter only applies to the ASA 5500 series adaptive security appliance. It is incremented when a connection that is being inspected by the SSM is terminated because the SSM has failed.
The card manager process running in the security appliance control plane issued system messages and CLI warning to inform you of the failure. Please consult the documentation that comes with the SSM to trouble shoot the SSM failure. Contact Cisco Technical Assistance Center (TAC) if needed.
This counter only applies to the ASA 5500 series adaptive security appliance. It is incremented when a connection is supposed to be inspected by the SSM, but the SSM is not able to inspect it. This counter is reserved for future use. It should always be 0 in the current release.
This counter is incremented for each unknown SSL record type received from the remote peer. Any unknown record type received from the peer is treated as a fatal error and the SSL connections that encounter this error must be terminated.
It is not normal to see this counter increment at any time. If this counter is incremented, it usually means that the SSL protocol state is out of sync with the client software. The most likely cause of this problem is a software defect in the client software. Contact the Cisco TAC with the client software or web browser version and provide a network trace of the SSL data exchange to troubleshoot this problem.
This is to indicate that the TCP connection is dropped because the SSL handshake failed. If the problem cannot be resolved based on the syslog information generated by the handshake failure condition, please include the related syslog information when contacting the Cisco TAC.
This counter is incremented when the UDP connection is dropped after the DTLS client hello message processing is finished. This does not indicatean error.
This counter is incremented for each malloc failure that occurs in the SSL lib. This is to indicate that SSL encountered a low memory condition where it can't allocate a memory buffer or packet block.
Check the security appliance memory and packet block condition and contact Cisco the TAC with this memory information.
This counter is incremented each time CTM cannot accept our crypto request. This usually means the crypto hardware request queue is full.
Issue the show crypto protocol statistics ssl command and contact the Cisco TAC with this information.
This counter is incremented when a decryption error occurs during SSL data receive. This usually means that there is a bug in the SSL code of the ASA or peer, or an attacker may be modifying the data stream. The SSL connection has been closed.
Investigate the SSL data streams to and from your ASA. If there is no attacker, then this indicates a software error that should be reported to the Cisco TAC.
This counter is incremented for each new socket connection that is not accepted by the security appliance.
It is possible to see this counter increment as part of normal operation. However, if the counter is rapidly incrementing and there is a major malfunction of socket-based applications, then this may be caused by a software defect. Contact the Cisco TAC to investigate the issue further.
It is possible to see this counter increment as part of normal operation. However, if the counter is rapidly incrementing and there is a major malfunction of socket-based applications, then this may be caused by a software defect. Contact the Cisco TAC to investigate the issue further.
It is possible to see this counter increment as part of normal operation. However, if the counter is rapidly incrementing and there is a major malfunction of socket-based applications, then this may be caused by a software defect. Contact the Cisco TAC to investigate the issue further.
This counter is incremented each time the security appliance receives a close alert from the remote client. This indicates that the client has notified us they are going to drop the connection. It is part of the normal disconnect process.
This message indicates either a misbehaving application or an active attempt to exhaust the firewall memory. Use "set connection per-client-max" command to further fine tune the limit. For FTP, additionally enable the "strict" option in "inspect ftp".
This counter is incremented when the source and destination addresses in a flow are the same. SIP flows where address privacy is enabled are excluded, as it is normal for those flows to have the same source and destination address.
There are two possible conditions when this counter will increment. One is when the appliance receives a packet with the source address equal to the destination. This represents a type of DoS attack. The second is when the NAT configuration of the appliance NATs a source address to equal that of the destination. One should examine syslog message 106017 to determine what IP address is causing the counter to increment, then enable packet captures to capture the offending packet, and perform additional analysis.
This counter will increment when the security appliance receives a packet on an existing flow that no longer has a valid output adjacency. This can occur if the nexthop is no longer reachable or if a routing change has occurred typically in a dynamic routing environment.
This counter is incremented when the virtual context with which the flow is going to be associated has been removed. This could happen in multi-core environment when one CPU core is in the process of destroying the virtual context, and another CPU core tries to create a flow in the context.
A flow is considered idle if standby unit no longer receives periodical update from active which is supposed to happen to at fixed internal when flow is alive. This counter is incremented when such flow is removed from standby unit.
A flow matched a dynamic-filter blacklist or greylist entry with a threat-level higher than the threat-level threshold configured to drop traffic.
Use the internal IP address to trace the infected host. Take remidiation steps to remove the infection.
When the system adds a lower cost (better metric) route, incoming packets that match the new route will cause their existing connection to be torn down after the user configured timeout (floating-conn) value. Subsequent packets will rebuild the connection out the interface with the better metric.
To prevent the addition of lower cost routes from affecting active flows, the 'floating-conn' configuration timeout value can be set to 0:0:0.
This counter is incremented when an SVC packet is received with an inner IP header that does not match the policy for the tunnel.
Check Nexus 1000V and verify that there are sufficient ASA 1000V licenses installed to support all ASA 1000V virtual machines in use. Use "show license" to check the available licenses for ASA 1000V and use "show license usage" to check the status of them.
This condition occurs when there is a failed attempt to place an event on the async lock queue for that connection.
This condition occurs when there is a failed attempt to place an event on the async lock queue for that connection.
Director/backup unit received a cluster flow clu delete message from the owner unit and terminated the flow.
A cluster flow was removed because it has stale owner info. Stale info can happen due to missing CLU_DELETE as normally this is not a reliable msg.
A cluster flow with CLU is considered idle if director/backup unit no longer receives periodical update from owner which is supposed to happen at fixed interval when flow is alive.
This counter is informational and the behavior expected. The packet was forwarded to the owner over the Cluster Control Link.
This is for cases that the packets from L3 subnet are seen by all units and only master unit need to process them.
A new unit joined the cluster and is now the director for the flow. The old director/backup has removed it's flow and the flow owner will update the new director.
Flow mobility moved this flow to another unit. This old fwder will be removed because it's turning into a backup.
Flow mobility moved this flow to another unit. This backup will be removed because new owner and director are on difference nodes.
Flow mobility moved this flow to another unit. This unit used to be both owner and director, now will host director flow only.
Either the scansafe server IP is not specified in the scansafe general options or the scansafe server is not reachable.
Another unit owns the flow, and asks me to delete my flow in order to create a director flow in its place later.
Another unit owns the flow, and asks me to delete my flow in order to create a forwarder flow in its place later.
Owner unit received a cluster flow clu delete message from the director unit and terminated the flow.
The cluster master may have just left the cluster. And there might be packet drops on the Cluster Control Link.
This counter is incremented when the security appliance sees an invalid VXLAN segment-id attached to a flow.
This counter is incremented when the security appliance fails to identify the NVE interface of a VNI interface for a flow.
This counter is incremented when the security appliance fails to get IP and MAC address of a peer NVE for a flow.
This counter is incremented when the security appliance fails to encapsulate a packet with VXLAN for a flow.
This counter is incremented when the security appliance fails to get the multicast group IP from the VNI interface.
Verify that in the absence of a configured peer NVE, the VNI interface has a valid multicast group IP configured on it.
This counter is incremented when the security appliance fails to find the peer VTEP IP for an inner destnation IP for VXLAN encapsulation.
Verify that in show arp vtep-mapping/show mac-address-table vtep-mapping/show ipv6 neighbor vtep-mapping, the VTEP IP is present for the desired remote inner host.
This reason is given for terminating a flow because the parent interface has moved from one VRF to another..
This reason is given for tearing down a conflicting connection in preparation for a new vpn stub connection.
Director/backup unit received an isakmp redirected packet from a forwarding unit and terminated the flow.
This counter should increment for every cflow torn down by isakmp redirected packet on the isakmp owner unit.
This counter is incremented and the flow is dropped when the IKE packet in this flow gets dropped due to corrupted or expired SPI.
Check the syslog to get more information about the origin of the packet. This situation can be normal and transient. If the drops persist, call TAC to investigate further.
The connection was torn down because the TCP packet exceeded maximum retries of retransmission, no reply from peer, tearing down connection.
The connection was torn down because the TCP packet exceeded maximum probe retries of retransmission, no reply from peer, tearing down connection.
The connection was torn down because the maximum probing time for TCP packet has elapsed, no reply from peer, tearing down connection.
The connection was torn down because the probe connection received RST from server, tearing down connection.
The connection was torn down because the probe connection received FIN from server, tearing down connection.
Another unit owns the flow, so need to delete my flow in order to create a director flow in its place later.
A packet with an address that matches a MAP (Mapping of Address and Port) domain Basic Mapping Rule has inconsistent encoding or the port number used is not within the allotted range.
フィードバック