Hallett_German

CA Tuesday Tip: The Seven Mysteries of TIM Communications

Discussion created by Hallett_German Employee on Aug 12, 2012
Latest reply on Sep 8, 2012 by Hallett_German
CA Wily Tuesday Tip by Hallett German, Sr. Support Engineer for 8/11/2012

Some time around 1984, I was privileged to hear the late Andrew Fluegelman give a talk. (See http://en.wikipedia.org/wiki/Andrew_Fluegelmanfor more details). It was titled the Seven Mysteries of Telecommunications. Fortunately, I did take notes from the talk which I have made into softcopy.

This article takes those original mysteries and retrofits them for TIM Communication. Going through these questions will help you in debugging problems.

1) Have I made a connection?

In order for TIM to "make a connection", it needs to be powered on, and "cabled" to see the HTTP/HTTPS traffic.

If the TIM or web console is accessible, check if the TIM receiving packets.

2) Are you speaking the same language?

The TIM and other devices need to speak "the same language." This can use
- Using the same speed and duplex
- Storing the same private keys as used by web servers, load balancers, and
firewalls.
- Using the same language encoding such as ISO8859-1 and UTF-8
- Using the same protocols such as TCP, HTTP, HTTPS, and SOAP/Web Services.

3)
Who are you talking to?
Is the TIM talking to a switch, firewall or load balancer? Knowing this will help in answering the following questions.

4)
Does your TIM/server understand?
What TIM "understands" is a topic in itself.
For example, TIM "understand" HTTPS traffic because of having the correct private key or not? An incorect or no key means the inability to record and see anything in the TIM logs.
A related issue could be a server could be using an SSL cipher suite that can't decode.

5)
What is the weakest link?
The "weakest link" is always changing in a monitoring environment. This can include:
1) Too much traffic over the network connection resulting in dropped packets.
2) TIM being over capacity on memory or CPU due to number of transactions being monitored, too many defects, SSL traffic etc.
3) The Database is unable to keep up with open connections.
4) The MOM or Tim Collector does not have enough heap size.
5) Issues with spans/taps/load balancer/firewalls/servers.

6)
Is it the fault of something else?
This can include such things as
- Firewalls/load balancers, etc. filtering out desired traffic or only allowing one way traffic. Another issue could be these devices could be sending TCP packets with various integrity issues so the HTTP content is unreliable or unreadable
- There is no path affinity so a request goes through one load balancer/firewall/web server and a response returns through a different route.
-Needed ports are not open

7)
Can you make sense of it all?
Trying to make sense of it all is a demanding effort requiring the following:

- Are we seeing the following in the logs?
-- connections opening and closing from users?
-- HTTP Logins and Sessions?
-- SSL traffic decoded?
-- HTTP Requests and Response (two-way traffic) from the same Client and
Server IP?
- Are we see the same traffic as a HTTP capture?
-- Are any headers stripped?

Answering these seven questions should make your TIM issues a little easier to determine.

Thanks Andrew for the insights and safe harbors on your journey.

Outcomes