Network Uptime

This brought up an interesting point when using a network analysis tool; there's always SOMETHING that can be made more efficient by using a network analyzer. I've had very few instances where using a analyzer on a network didn't provide me with at least _one_ opportunity for improving the throughput of the network!

When visiting other companies, I sometimes find that many of the network managers are only using their network analyzer in times of trouble or chaos. The rest of the time, these tools are unplugged or under someone's desk! A quick weave of a network trace can lead to many tangled webs. Here are some issues to check on your network:

* Broadcasts - With the proliferation of switched networks, many network managers have moved from a routed configuration to a flatter network design. Unfortunately, this also means that more broadcasts are finding their way around the network! Try to keep broadcasts under 40 per second, and don't let them exceed 120 per second!

* Unwanted Protocols - In with the good, out with the bad! Almost every network has a protocol that shouldn't be there - my network was a perfect example!. Most analyzers can display a protocol distribution table which would identify any protocol that communicates on the network. Here's an example: One very common protocol on many switched networks is the Bridge Protocol Data Unit (BPDU). BPDUs are multicasts that allow switches to communicate with each other for spanning tree configuration and keep-alive messages. The default configuration of many switches is to have spanning tree enabled, even if the network has no redundant switched links. Since most BPDU keep-alive messages are sent every two seconds, disabling spanning tree on a switch can save a packet or two of bandwidth!

* Bad Applications - They don't mean to be bad, they're just written that way. A good example of a 'bad' application is the code that was written into a popular printer brand. When used with a NetWare server, the printer would poll the file server every two seconds to query for a print job. One minute of packet capture would show 60 frames traversing the network (one for the request, and one for the answer). If 10 printers were placed on the network, the number of frames would increase to 600 per minute, and that's without ever printing anything!

In this case, the timeout for the printer was adjustable. Setting the default value to 30 seconds decreased network traffic without causing much of a delay to the waiting print jobs.