Network Performance archives - IT Trenches

IT Trenches:

network performance

Sep 30 2009   1:06PM GMT

Where do TCP resets come from?



Posted by: Troy Tate
tcp, udp, network management, network performance, network monitoring, application performance, network analysis, performance analysis, protocol analysis, packet capture

I recently came across an excellent article on the topic of TCP resets. TCP is a connection-oriented protocol as opposed to the connectionless nature of UDP. So, if there are TCP resets on your network, this is not a bad thing and is just inherent in the protocol. Without TCP resets, a host could have a lot of partial connections established which are in the wait state awaiting further transmissions. This can exhaust the number of available sockets and cause the host to become unresponsive. This is what happened several years back with the TCP SYN flood and LAND denial of service attacks. Another reset type includes the ACK/RST. This is where a client attempts to connect to a service that is not available on that destination host.

If you manage a network and have taken packet captures to work on a problem and have seen RST packets or if you need to do this at some point in your career, you need to understand the purpose and source of the RST packets. Take a few minutes, read this excellent article that is the best explanation that I have seen on this topic. You will become better informed and better able to understand the nature of the network beast.

Where do resets come from? (No, the stork does not bring them.)

Thanks for reading and let’s continue to be good network citizens.

Sep 30 2009   12:33PM GMT

Heard in passing - IT Trenches support at its finest



Posted by: Troy Tate
humor, network performance, education, network support, user education

Okay - if you support networks and have to explain why the network is slow or application performance is not what the users expect, why not use some of the following responses? These statements may or may not have been used in real life. What responses have you given to users when there really wasn’t a problem?

  • Unfortunately we have run out of bits/bytes. Don’t worry, the next supply will be coming next week.
  • The routing tables are all filled. There is going to be at least a 15-20 minute wait until you can be seated.
  • Those packets have to go uphill to their destination. Gravity impacts network performance when you access services at that location.
  • That is due to a BNC error. (i.e. brain not connected)
  • The developer used a spell checker on that program. The fix will be delayed.
  • The parallel processors are running perpendicular today.

Maybe a smile came to your face today while reading this. Maybe you have some similar comments to share with ITKE readers. Feel free to leave some words of wisdom for other IT Trenches members.

Thanks for reading & let’s continue to be good network citizens.


Sep 25 2009   3:15PM GMT

Performance monitoring dashboard - fping and URL ping



Posted by: Troy Tate
ping, url ping, network performance, application performance, network management, application management, network design, network diagnosis, icmp, web services, webserver, performance analysis

In part one of this series, I discussed ping and pathping. These tools are good for some interactive realtime testing. However, what do you do when you want to run these types of tools over an extended period and then do statistical analysis? In cases like this I use the fping tool. I recently completed an analysis task requiring comparison of network ping times against web server response times. The tool I used for measuring webserver response (time to first byte) is called URL ping. Users were reporting slow webserver (Sharepoint) performance. Everyone was saying it is a network issue. Since there are so many “moving” parts between the users and the webserver farm, I wanted to prove to them that the network was not the issue but that something inherent in the way the webserver responds to the requests is the real issue.

Continued »


Aug 28 2009   4:57PM GMT

Performance monitoring dashboard - designing and instrumentation



Posted by: Troy Tate
ping, pathping, network performance, application performance, network management, application management, network design, network diagnosis

One of my biggest challenges as a network manager is when users cry “the network is slow”. Some of you may have tools available to you where you can instantly dig in and see what the user might be seeing. There are some vendors out there with application and network monitoring tools. Netscout is one that comes to mind. However, I don’t have tools like that available so I have to work through several layers of data collection methods and tools to get a picture of what might be happening. Maybe you are in the same boat. Getting an answer to “the network is slow” is not a simple or quick activity. How do you deal with this? Following are some ways that I use to try and address the situation.

Continued »