NUT – Network Utilization Testing Plugin for LabTech

header

NUT uses IPerf to test between 2 endpoints. When launching a scan with NUT we send commands to both systems to start the IPerf executable. The Host side and the Client side sessions are sent start up commands and the client is then pointed to the host to run the configured scan options. Once the scan is complete the results are returned to the plugin console menu.

The Host side must have firewall access on the port and protocol you select (default is 5001 and TCP). You will also need to supply a FQDN or routable IP address for the host system to allow the client to locate the host system across the internet and to connect. 

You can select TCP or UDP protocols and how long to run the test from the config menu.

 

launchwindow

 

 

In version 1.0.1 we are forcing the host side to be one system under client 1. We are using our LT server as the host side and have opened up ports to allow UDP and TCP testing on port 5001. You can select any system to be a host just remember to make sure to allow firewall access to host and that host has a external FQDN or IP to allow access from other locations.

In version 1.0.2 we added the servers at any clients location to be added to the Servers side of the IPerf testing. Fixed a could minor display issues.

Version 1.0.2

 

download

Buffer Bloat, a minis to the TCP protocol

Today I would like to take a minute of your time and talk about Bandwidth usage and a little known  phenomenon called Buffer Bloat.

 

What is Buffer bloat and what does it effect?

 

Buffer bloat is the product whereby excess buffering of packets inside the network causes high latency and jitter, as well as reducing the overall network throughput. Buffer bloat occurs when a network link becomes congested, causing packets to become queued in the buffer of a router or switch. As traffic passes from one router to another this buffering can become amplified. Amplification of Buffer bloat happens as each router segment buffers the netflows, the more router segments between the endpoints the larger the bloat can grow. The problem is caused mainly by router and switch manufacturers making incorrect assumptions and buffering packets for too long in cases where they should be dropped. Dropping packets is not always a bad thing. TCP is built so that when packets are dropped the protocol slows the transmission down. Transmission speeds up and slows down until it finds an equilibrium equal to the speed of the link. However, for this to work the packet drops must occur in a timely manner and buffering packets negates this process.

 

In a network buffer (router memory), packets are queued before being transmitted and in the problematic situation packets are only dropped if the buffer is full. With the advent of cheap RAM router manufactures have been adding more and more RAM to their systems allowing for larger and larger buffers. On older routers, buffers were fairly small so they filled quickly and therefore packets began to drop shortly after the link became saturated, the TCP protocol could adjust, and the issue wouldn’t become apparent. On newer routers buffers have become large enough to hold several megabytes of data, which translates to 10 seconds or more at a 1 Mbit/s line rate.

 

The problem is not limited to just TCP, these problems also affects other protocols. All packets passing through a simple buffer implemented as a single queue will experience the same delay, so the latency of any connection that passes through a filled buffer will be affected, this includes protocols like ICMP and UDP.  If you have read this please send me a email back, I would like to see how many of us out there read this far.

 

Want to learn more about Buffer bloat and how it effect endpoints and company networks? Please visit this article on Buffer bloat at http://gettys.wordpress.com/2010/12/03/introducing-the-criminal-mastermind-bufferbloat/