Interpath Application Flow Diagrams-01

This article is also covered as a podcast on "The ROOT Cause" podcast series, available on iTunes.

Interpath Application Flow Diagrams have been the second most frequently read or listened to topic on the Interpath Technologies website and The Sniffer Guy / The ROOT Cause podcast series. While it has been discussed in previous articles and podcasts, I felt it warranted some more attention. It is also the most frequent request we receive in emails. People are looking for templates. In response, we are creating a list of templates but it is a difficult process because each situation is unique. That being said, there are many similarities and common mistakes.

An Interpath Diagram (application flow diagram or process flow diagram) is NOT a network diagram, although there are similarities. When I ask for this type of diagram, nine out of ten times, what I receive is a Network Diagram. Let’s discuss the differences.

Interpath Application Flow Diagram:

-- Contains Layer 4 Port (TCP or other) information.

-- Shows what IP addresses communicate with what other IP addresses and what protocols they use to do so.

-- Is very concerned with "Tier" information. How does a message get from source to destination?

-- Contains IP addresses--both actual and virtual, including all physical interfaces on the box.

Network Diagram:

-- Shows infrastructure such as Routers and Switches.

(This may also be needed as supplemental information for the project, but is not a typical part of the Interpath Application Flow Diagram.)

-- Shows routing information.

-- Contains IP addresses: both actual and virtual, including all physical interfaces on the box.

(An area of overlap with the Interpath Application Flow Diagram.)

The focus is entirely different. The Network Diagram is concerned with how data moves from one subnet to another while the Interpath Application Flow Diagram is focused on how data moves between the source computer and the destination computer—to the next destination computer--to the next destination computer, and how long each computer takes to perform its job. It is more about tiers than switches.

These are the goals of the Interpath Application Flow Diagram:

To allow for the creation of Transactional Test "Click Streams" that can be used to show test users exactly what actions to perform during a test session.

To guide the Test Designer in where to place the physical Packet-Sniffers (e.g. Wireshark) in the infrastructure. Since the Network Application Performance Analyst (NAPA tm) is not going to be the one to create the port mirrors (SPANs) or place the packet-sniffers themselves--knowing the Network in great detail is not necessary. What is critical is being able to know from a transactional flow, what IP addresses need to be monitored. The Interpath Application Flow Diagram is able to provide that level of detail. This way, the Network Application Performance Analyst (NAPA tm)can inform the Network Engineer, who will be doing the Port Mirroring (SPANing), where visibility is needed--depending on what part of the transaction needs to be seen and is being tested.

Templates for clear and simple Interpath Application Flow Diagrams can be seen on interpathtech.com

One major area of confusion is with IP addresses. Odd as it may seem, if you really ask, you may find that the IP addresses are not known for the various component servers. There are Physical Interface IP addresses, Virtual IP addresses, Production IP address, Management IP addresses and IP addresses for different applications or database instances. It is very likely that no one knows them all. Similarly, it there is usually no planning of TCP port designation. In some cases, a team may select a TCP port for an application that is actually be a port that is commonly (if not formally) used for another application, thereby confusing packet-sniffers and other monitors. All of this must be clearly stated in an Interpath Application Flow Diagram.

Article Source: http://www.contentspool.com

Barry Koplowitz founded Interpath Technologies Corporation in 1999. He was an instructor for Network General and NAI traveling around the USA teaching for Sniffer University and is a executive consultant to large enterprise environments in the area of Processes-Network/Application Analysis and Troubleshooting. He is the writer and host of The ROOT Cause podcast. www.interpathtech.com

Please Rate this Article

5 out of 54 out of 53 out of 52 out of 51 out of 5 

Not yet Rated