show acl-merge merged-list

Displays the acl-merge list per-context for a specified VLAN. The ACL-merge list is a single ACL (access control list) that the CP compiles from multiple security ACL entries and policies present in the configuration. The information displayed by this command represents the actions that the ACE will perform on a flow based on this acl-merged list.

Packets were dropped. Typically, the "Packets dropped" value is slightly less than "RX packets" value during normal operation. Reasons for packet dropping include the following:

Invalid source IP/MAC address

The flood ARP handling option is not enabled and the interface is not bridging. (This counter will be incremented along with the "Smac-validation failed" counter.) If debug mode is enabled, these error messages are produced:

debug arp err – "ARP DAI checks failed. Dropping pkt!"

debug arp err – "Dropping pkt with smac-validation failure..."

Packet received on the standby and not for the standby IP. If debug mode is enabled, this error message is produced: debug arp info - "::Cannot bridge or process ARP pkt ip:xxx".

The entry is in the ARP cache but a failure occurred in getting the MAC address from ARP entry. If debug mode is enabled, this error message is produced: debug arp err – "Failed to Get mac addess from ARP entry!".

The address is "owned" by the ACE because it is an interface address of the active/standby or any other local address (alias, vip, nat) on the active.

ARP cache entry creation failed.

If the entry is not in the ARP cache or if it is a local entry and is not bridged.

If bridging and if sourced from or destined to the standby ACE. If debug mode is enabled, this error message is produced: debug arp info – "Dropping Packet source/dest ip xxxx is of standby module".

Drop ARP response packet if the destination entry is found on the same interface as the source, or is a unicast flood packet. If debug mode is enabled, this error message is produced: debug arp err – ":: Dropping Response Packet.. unicast flood".

Whenever the DP (ICM or OCM) encounters an encaps ID of 0 for packets, it makes an IPCP call to the internal ARP Manager to resolve the encaps ID. This counter indicates the number on the encap miss message sent by DP to CP for encap resolution.

After receiving Encap-miss message, if the IP address is directly connected to ACE, the ARP Manager sends an ARP request to get the mac resolved for the IP else if the IP is not directly reachable, ACE sends a ping message to the IP address; all the stats below are related to when the ARP Manager sends the ping to resolve the MAC of the next hop.

Pings attempted for Encap-miss msg

Number of times that the ACE recognizes that a ping attempt needs to occur when an Encap miss due to destination packet IP address not on an existing bridge-group subnet occurs.

Pings quenched for Encap-miss msg

Number of times that the ACE suppresses an effort to ping for the same destination packet IP address if the Encap miss for that address occurs repeatedly and too fast.

Pings rejected for Encap-miss msg

Number of times that the ACE rejects ping attempts for destination IP addresses when the Encap misses for that address are too many to handle. Similar to the quenched pings, these misses are unique.

Pinged Encap-miss responded to

Number of actual pings sent for a missed IP address. The number of this counter should match the number of pings that were attempted for the Encap-miss message counter.

Replication Counters

These counters are related to the number of messages exchanged between active and standby. Standby gets sync messages for hosts which are learnt by the active.

show buffer event-history

This command is primarily intended for internal use. It displays a historic log of the most recent messages generated by the diagnostic buffer event manager. It is used in conjunction with the diagnostic command debug buffer.

Note that the buffers referenced in the command are zero-copy buffers shared between the ACE user-space and the ACE kernel drivers.

The hexadecimal numbers printed are ACE kernel virtual addresses indicating where the buffers are located.

The two buffer pool virtual addresses for the control (ctrl) and data buffer pools.

show buffer stats

This command shows detailed counters for various buffer manager event occurrences. Specifically, it shows statistics for the control plane's buffer, with stats for DEFAULT_CONTROL pool, DEFAULT_DATA pool (which are automatically created at initialization) and total count.

You should provide the output of this command, along with that of show buffer usage, to Cisco TAC in the event of buffer manager errors, for instance, as indicated by the error message: "No memory from buffer manager. Cannot send packet."

This is the maximum value of available buffers ever. That is, the "max of (Total Buffers - In use) all time".

Lo watermark

This is the lowest value of available buffers ever. That is, the "min of (Total Buffers - In use) all time".

show buffer usage

This command displays the number of buffers currently being held (allocated but not freed) by each buffer module. The "Multiple Frees" column shows an estimate of the number of times a particular buffer module has freed the same buffer more than once (this indicates a software error condition).

The show buffer usage command displays the per-owner usage array. This is useful for identifying error conditions in which the module is not freeing buffers or freeing the same buffer multiple times.

You should provide the output of this command, along with that of show buffer stats, to Cisco TAC in the event of buffer manager errors, for instance, as indicated by the error message: "No memory from buffer manager. Cannot send packet."

A module to test buffer allocation/free from kernel module context; it uses the buffer for testing the kernel programs.

Pkt Fifo Driver

FIFO driver module. As shown in the sample output, this is typically a large value.

VNet Driver

Linux Pseudo-Driver module.

IPCP

IPCP driver module.

Arp Manager

ARP Manager events; usually incremented by ARP requests and responses.

BPDU Handler

BPDU fixup/forwarding handler module.

Session Filter

IXP Session Filter module.

show cde all

Displays the values of all Classification Distribution Engine (CDE) registers. The CDE is a component within the ACE module that acts as a central point of contact between all the main components in the module. It is a field programmable gate array (FPGA) that can be thought of as a smart switch within the ACE; it decides where an incoming packet should be sent among the various components on the ACE.

Several show commands provide information on the status of the CDE. A few notes on these commands:

They are module-specific

They can only be performed in the admin context

Except for the show cde health command, these commands are primarily used for internal development purposes and not relevant to general troubleshooting. However, they are listed here for completeness.

As shown, statistics cover a range of CDE gates for the components in the ACE module. Values are indicated in hexadecimal number format. Also note keep in mind that there are actually two CDE units, cde1 and cde2.

Many of the following commands are related to this one and represent a subset of the information shown here. The descriptions for those commands may provide more information on specific fields.

show cde count

This command is a form of the show cde command that indicates whether multicast packets (generated by the CDE and reflected back by Hyperion) have been dropped by the Hyperion receive registers (HR). The Hyperion ASIC is the packet rewrite, multicast, and SPAN engine used by the ACE to receive connections over the Cat6k Switching backplane.

In the sample output, the count indicates that packets have been filtered by the CDE. This is not unusual. In this case, a component of the ACE has generated a multicast packet which was sent through the CDE to the Hyperion ASIC that serves as the interface to the Cat6k switching backplane. The Hyperion ASIC, recognizing the message as a multicast message, floods it. The Hyperion receive registers on the CDE drop the packet.

show cde health

For purposes of general troubleshooting, this command is the most useful of the CDE-related show commands. It can be the best place to start to inspect the internal status of the ACE Module infrastructure.

Its output describes the CDE ports, the interfaces between the CDE and all other components of the ACE Module.

HYPERION is the ASIC from which/to which the CDE receives/sends data traffic.

IXP0 and IXP1 are the two network processors

NITROX is the SSL hardware decrypt/encrypt chip.

In general, the components should:

show a "healthy" status for spi src/snk.

show "pulling" for "component pull status" (the exception being the BRCM, which may show "not pulling" even when pulling. (There are CDE registers which can be used to find out if this is problematic condition or just a false align.)

show their queues as "empty"/"not full".

have incrementing packet receive/send counters.

Conditions other than listed would be considered unusual and warrant further investigation.

show cde int

A form of the show cde command that shows only the CDE interrupts and masks. This is information on the internal operation of the ACE Module hardware and in general useful only to internal development.

show cde stat delta

For the CDE statistics that indicate packets, transmits, and errors, this command shows the value differences since the previous time the command was run. This is primarily useful for internal development to learn how traffic is moving through the module.

To use the command, you would typically run it several times to see how traffic is affecting the statistics for particular registers.

show cfgmgr internal table rserver

Displays the internal ID for the real servers (rservers) configured in the active context. This information is useful for performing certain troubleshooting tasks, such as using LbInspectTool. LbInspectTool is a software tool used by Cisco support personnel to inspect data structures associated with the loadbalancing process that runs on the dataplane.

The internal ID number for each server farm is shown in the Sfarm-Id column. This is the value that the LbInspectTool command takes as input to produce information for that server farm:

'1 - Inspect tables ' / 'd' - DRAM / 's' - Server Farm / 'Enter ID: '

show cfgmgr internal table sfarm-real

Lists the real servers along with their associated server farm in the context. This command differs from the show cfgmgr internal table rserver command in that show cfgmgr internal table rserver displays one index for each physical rserver, whereas this command displays an entry for each occurrence of the rserver in a serverfarm.

In other words, a real server that is in multiple server farms will be shown multiple times.

An authgroup specifies the list of CA certificates that the ACE will use to authenticate its peer certificate. This is required if SSL initiation is configured (to authenticate the server), or if ACE is configured as an SSL server and client authentication is configured.

The fields displayed in this command are, for each certificate in the authgroup:

Subject: The distinguished name of the organization that owns the certificate and possesses the private key.

show crypto cdp-errors

A CDP is a CRL distribution point. This command lists the number of times various errors were encountered when trying to parse the CDP.

The counters and the reasons they are incremented are:

Counter

Reason

Incomplete

There is no '/' nor ':' in the CDP. There is no hostname in the CDP filename or base and attributes not provided. If you enable SSL error debugging, you will see this message.

Improper length of the filename or base and attrs

If you enable SSL error debugging, you will see this message; could not find "certificateRevocationList" or "certificateRevocationList;binary" in the LDAP URI; LDAP URI scope is not "one", "base", or "sub" filter in url NOT cRLDistributionPoint or wrong format; if you enable SSL error debugging, you will see this message; something wrong in the URL, ignored (the LDAP URI is > 255 characters); if you enable SSL error debugging, you will see this message.

Unrecognized Transports:

CDP does not start with "http://" or "ldap://"; if you enable SSL error debugging, you will see a message.

Missing from cert

received cdp missing indication from DP; if you enable SSL error debugging, you will see this message.

Best Effort CDP Errors Ignored

The revocation of the cert needed to be reverted based on CDP issues found in the cert. This is applicable for best effort CRLs only (A3(2.x) and later)

show crypto certificate

With the all keyword, this command shows summary information of all certificates in the context. When you indicate a specific certificate in the command, it shows details for that certificate.

The distinguished name of the organization that owns the certificate and possesses the private key.

Issuer

The distinguished name of the CA that issued the cert.

Not Before

Starting time period before which the certificate is not considered valid.

Not After

Ending time period after which the certificate is not considered valid.

CA Cert

Indicates whether this cert belongs to a Certificate Authority.

show crypto chaingroup

Shows the certificates in a specified chaingroup or all chain groups. A chain group specifies the list of certificate that the ACE sends to its peer during the handshake. A certificate chain is a hierarchical list of certificates that includes the subject’s certificate, the root CA certificate, and any intermediate CA certificates in between.

The following counters are of interest when determining whether or not the Nitrox-II is "stuck":

Field

Description

STX1/IMX1 packets

Packets transmitted/received over SPI by the Nitrox-II. On a normal system these values should be equal when traffic has stopped flowing.

TX Buffers used

Buffers in use by the Nitrox-II for transmit

RX Buffers used

Buffers in use by the Nitrox-II for receive

available_cores

Shows which of the 22 Nitox-II cores are in use

POM count

Outstanding requests to the Packet Order Manager. The number outside the parentheses is the number of outstanding requests.

TX Backpressure

Number of SPI cycles that the Nitrox-II receives backpressure when trying to transmit data to the CDE.

RX Backpressure

Number of SPI cycles that the Nitrox-II exerts backpressure to the CDE.

Once traffic has stopped flowing, the RX/TX buffer counts and POM counts should go to 0. All cores should also be available, i.e., (Using:). If the values of the RX/TX buffers ever go above the value 0x800, then the chip has effectively crashed.

Also look at the TX Backpressure and RX Backpressure counters. High values for these indicate that the system is under some sort of stress.