CA Tuesday Tip: Is the Issue on the MTP or TIM side?

Discussion created by Hallett_German Employee on Jun 8, 2013
Latest reply on Oct 15, 2013 by GauravPartap
CA Wily Tuesday Tip by Hallett German, Principal Support Engineer for 6/8/2013

The MTP or Multi-Port Monitor (formerly known as Multi-Port Collector) provides additional throughput capacity unimagined with a Timsoft. (By the way MTP is an acronym from (M)ul(T)i (P)ort.)

This Tuesday Tip provides a framework to help in determining if the issue is on the MTP or TIM side of the appliance.

[center] What isn't working ?[center]
Here are some common scenarios if the functionality is failing on the MTP side:

- The MTP is not collecting data.
The APM for IM Guide mentions that the Napatech Card Time is different than that of the Network Time Protocol Server. But there could be other scenarios:

* The Napatech card is misconfigured.
* The MTP network connection to a span/tap/aggregator/etc is incorrect.
* There were residual problems from the MTP install/upgrade.

- The MTP is collecting data but running out of space. Or the MTP is restarting frequently
This would be very evident from errors in the logs, seeing a non-zero value
in the nospace column of protocolstats logs, viewing the Ramdisk filespace at 100% by issuing a df command at the MTP console, etc.

The cause of this could be the RAM Disk being too small or the network traffic at a customer is filled with various data integrity issues (such as out of order packets, packet retransmissions) that can be resulting in large packet capture files.

Another cause is the ramdisk is adequate but inadequate hardware filters are in place. This would result in receiving more traffic than actually needed.

Note the recently released TIM Monitor Fieldpack can alert when ramdisk runs out of space as well as other error conditions. It is freely available with As-Is Support.

- The MTP is collecting data but not seeing traffic from a particular server.

The MTP appliance can do filtering at two locations:
The MTP hardware filter (Administration>Logical port) is filtering out traffic from particular ports, VLANs, or IP subnets.
The TESS Web Server filter does not include certain IP addresses so it is excluding traffic. With MTP appliances, it is recommended to do the filtering on the MTP side with the hardware filtesr rather than on the TIM side with the web server filters.

Here are some common scenarios that the data is failing on the TIM side:
- The MTP is collecting data but there are other issues.

As long as the data in the "Forwarded from MTP" column is a non-zero number, MTP is doing its job. Several Tuesday Tips have already been written on common isues on the TIM side. Things to check on MTPs would include:

- If there is SSL traffic, are the ciphers being used by an application supported? Is the private key correct? If bad traffic impacting SSL decoding?

- Are there issues with TIM Plug-ins (SiteMinder, XML, Flex. custom)causing extra load?

- Is the definition configured correctly on the TESS-MOM?

- Is the domainconfig.xml file on the TIM correct?

- Is the TIM communicating correctly with MOM, Collector and database? (Resulting in 4xx/5xx messages in the Events viewer)

These are the discussion questions for this article:
1. Has this been helpful as a first step in triaging MTP vs TIM issues?
2. What is the Ramdisk on your MTP currently set to? Is that the original value?
3. How has the inclusion of network data with APM CE defects helped you in improving application health and customer satisfaction?