The percentage of alien packets

The percentage of packets that are encountered in the capture stream that the PCA cannot associate with an existing connection. When capture is first started, this number is expected to be a high percentage. But as capture continues to associate and process hits, this figure must drop.

Analysis: If this metric is marked in red, the quality of the data that is sent to the PCA or the TCP connections must be improved. Here are some suggested approaches.

1. Apply traffic filters: If you not done already, you can apply filters to remove unwanted traffic that is being forwarded to the PCA. Traffic filters can be applied to port ranges or IP addresses.
2. Capture Mode: If the PCA is configured to be in BusinessIT mode, more data is captured, which cannot be important. Alien packet counts can drop if you switch the PCA to capture in Business mode.
3. After you make changes to the above, you must restart the PCA.
4. Check hardware: The SPAN port that is used to deliver hits to the PCA can be dropping some, due to oversubscription. Verify with your IT department that data is not being lost by the SPAN port.

   High alien packet counts and missing pages can be associated with improperly functioning NIC card on the machine hosting the PCA. You must also review and update, if needed, the driver for the NIC card.

5. Bad checksums: If there are a significant number of bad checksums, you must check with your IT staff to verify that the source of the traffic that is forwarded to the PCA is generating valid checksums.

   To test the validity of the checksums in the packet data, you can enable checksum validation through the Interface tab. Validation is enabled by default.

6. Additional information can be available in the statistics log, which you can download from the PCA web console.
7. You can enable archiving in the PCA, which delivers raw network packets to the designated archive and can be useful for debugging issues in session data.
   Note: Use of the PCA archiving features must be conducted under the guidance of Support personnel. For more information, contact Tealeaf® Customer Support.

If true, reassd cannot keep up with listend

The listening (listend) process in the PCA instance is sending more hits to the reassembly (reassd) process than it can evaluate. As a result, hits are being dropped.

Analysis: If this metric is marked in red, you must configure the PCA to send fewer hits through the individual instance of the PCA. Some suggestions:

1. Add PCA Instances: Adding instances of the CX Passive Capture Application to the hosting server can alleviate the traffic volume to individual processes.
2. Listen on more ports: Adding listen ports to the PCA can reduce bottlenecks in the processing over any individual port.

The percentage of dropped packet connections

This metric identifies completed connections that the PCA suspects dropped packet conditions.

Analysis: This problem is caused by the connection between the PCA and the device that is feeding it. Review the listen configuration for the PCA, the output configuration for the sending device, and the network topology in between.

The percentage becoming unidirectional traffic

This metric indicates the percentage of traffic that is passed to the PCA that moves in one direction. To reassemble a hit, the PCA matches requests (traffic moving between client browser and web server) to responses (messages that are sent back to client browser based on requests). To capture a visitor's experience, the PCA must receive all bidirectional traffic.

Analysis: Typically, this issue is a configuration problem with the device that is responsible for forwarding data to the PCA. Consult with your IT department to verify that the SPAN port or switch is forwarding bidirectional traffic across all Tealeaf ports.

When the PCA detects unidirectional hits, those hits can be dropped. For request-type hits, can result in a request canceled hit, with no corresponding response present in the capture stream.

The rate reassd is currently reassembling non-SSL hits

This metric indicates the core processing rate of the PCA. Typically, an instance of the PCA must be able to process between 400-600 hits per second. For SSL traffic, the process rate is typically 200-300 hits per second.

Analysis: If this rate drops too low, then the reassd process is overburdened. The following items can be investigated to try to improve processing rates:

Check privacy rules: Privacy rules that are applied in the PCA can be expensive in terms of processing, especially if you are using regular expressions to assess the data. Wherever possible, avoid by using regular expressions.

• Use privacy rules to block or encrypt only the most sensitive data.
• Privacy evaluation can be moved from the PCA to the Windows™ pipeline, as needed. While applying privacy in the PCA ensures that sensitive data never displayed in the Tealeaf system, non-critical privacy processing can be applied through the Windows pipeline, by using identical rules configuration.

If true, encountered Diffie Hellman SSL

If this metric is marked in red, the PCA encountered the Diffie Hellman SSL cryptographic algorithm, which is not supported by the PCA.

Analysis: The CX Passive Capture Application is unable to capture traffic in the presence of Diffie Hellman. It is recommended that you reconfigure your web servers to not use this protocol. For more information, see the documentation that came with your web server product.

The percentage of aged connections

This value indicates the percentage of TCP connections that are captured by the PCA that timed out. Aged connections can result in abnormally terminated sessions in the Tealeaf data.

Analysis: High percentages of aged connections can indicate a network configuration issue. It happens as the connection timeout indicates that the PCA is waiting for data that is never delivered.

• By default, the PCA is configured with a timeout setting of 60 minutes.
• PCA connection timeouts can be configured through the ctc-conf.xml file. The setting is <AgedTcpConnectionsTimeout> in the capture section.

Missing SSL keys/sec

This metric indicates the number of missing SSL keys that are detected in the traffic each second.

Analysis: When this metric is marked in red, the SSL keys are updated on the web server, yet the PCA is not provided with the new keys. Without the proper SSL keys, the PCA cannot decrypt SSL-based traffic, and those hits are dropped.

You must acquire the new SSL keys from the web server. Contact the IT team responsible for your web servers.

Filtered traffic kbytes/sec

This value indicates the kilobytes per second of traffic that is being captured by the PCA after any configured filter rules are applied.

Analysis: If this value is too low, then you can have a problem with the data filters that you apply through the PCA. You must review the filters that you applied.

To assess the quality of your filtering, you must review the quality of the data that is captured. Through replay, you can quickly identify whether meaningful hits are being dropped.

If non-zero, hits are being dropped due to an overloaded pipelined.

When this value is not zero, the indicated number of TCP packets were dropped from the pipelined process due to overloaded conditions.

Analysis: This value must not be zero. You can specify the maximum permitted size for individual TCP packets through the Tuning Parameters in the Interface tab.

If some hits are dropped, the overload condition can be caused by too many privacy rules or too much complexity in them. You can add more instances of the pipelined process, which can help to distribute the processing load.

When this statistic is summed across all PCA instances, the result indicates that the total number of hits lost due to exceeding the specified TCP packet size. To calculate the % of total, divide this value by sum of the Captured before hit processing statistics for all PCA instances, which is the total hits count for delivery to the pipeline queue.

Increasing the number of pipelines under the pipeline tab can help alleviate this issue.

If non-zero, packets are being dropped because they exceed the max size limit

Whenever a packet is received with a size larger than the maximum large capture packet size limit, this metric is incremented by one.

Under the Interface tab in the Tuning Parameters view, the Max large capture packet size field defines the maximum large capture packet size limit.

• By default, this setting is set to 8 KB.
• As needed, this setting can be increased to accommodate systems that have features such as large receive offload (LRO) enabled.

Increasing the Max large capture packet size must stop metric on the Summary tab from increasing.