As I’m sure you’ve noticed by now, we cover a lot of networking ground here. Whether it’s network design, cable management or monitoring your internal systems, all of them interest us equally.

As a network designer, one of the components of network design that we are very concerned with is the amount of bandwidth that each known application on the network will generate, and when we can expect that traffic. We are also concerned with possible applications that may reside on the network at some point in the future.

For a simple network, one that only has desktop computers and servers, it’s fairly simple in most cases to determine what the traffic is, where on the network we need to be concerned and when we can expect to see maximum traffic. For the most part we concentrate on things like network backup of various servers - usually you see spikes in traffic in the datacenter or server portion of the network during backup periods. For the most part that is the big traffic challenge on a simple network.

Beyond on the simple network, you start seeing networks that ramp up in what they have on them - usually it moves from very simple to having some phone traffic. Then video conferencing. Then CCTV. Then security system. And on and on it goes.

Designing networks that can expand easily to cover the possible traffic on the network is something of an art form. The existing requirements are easy to design for, but seriously, 5 years ago (not an unusual amount of time for an enterprise network to be in use) who would have thought that CCTV camera systems would be run over the data network almost exclusively, and be running upwards of 5 megapixel streams of video? Or how many people designed networks knowing that video over IP would be all the rage, with 1080p channels being streamed multicast over standard data network infrastructure?

I’d like to say that I did, but even though I was building networks for IP based CCTV back then, I really wasn’t thinking about such high resolution CCTV streams or HiDef Television programming.

But over the past year I’ve been designing some very large scale networks that have been designed to handle all those kinds of traffic and more, all on standard networking technologies. At very high uptime requirements. And believe me - at this point it’s all about network bandwidth management at this point.

Now, with that said, one of the smaller amounts of traffic on these large networks is monitoring traffic. The pings, SNMP gets and netflow streams that we use to monitor all the components of very large scale networks is generally among the smallest amount of traffic by volume on the network.

But even with the amount of traffic being relatively small, it’s still something to take into account. And if you are running an older network, it can be a significant part of the traffic that you have on the network. And that is where you really need to control what you are monitoring and how.

For instance, if you are running a fairly small WAN, say 3 T1 lines from your central office to smaller offices, and are using IP phones and IP conferencing, you really want to keep the amount of traffic on the WAN links as small as possible to allow your business applications to be able to fully utilize the bandwidth you are paying for. But you need to monitor what’s going on in those remote offices still, so how do you do it?

In that example, I would recommended that your base monitoring is a 5 minute ping, with SNMP gets (from MRTG or Cacti) to the WAN and Ethernet interfaces of your router. Then PING your switches every 5 minutes, along with any other critical devices, just to make sure they are up and responding.

Then move any traffic analysis off the remote office routers, and onto your central office WAN router. That would be monitoring applications like Netflow or something similar. That way you still have the neflow data coming into your sensor, but it’s not crossing the expensive WAN connections. And by cleaning up your SNMP gets to only grab two interfaces, you are further reducing your monitoring traffic, while still allowing you a good view of what’s going on remotely.

If you have very expensive, small WAN connections between larger offices, another choice is to place a monitoring server in the remote office, just passing the results back to your central server. Nagios allows you to do this, as do several commercial products. Setting up your monitoring to use remote servers reporting back to a central server is great for bandwidth, but be forewarned that it’s not that simple to setup. In fact it can be a real pain in the ass. But it is worth is if the situation is the right one for that type of setup.

Overall I recommend being aware of your monitoring traffic, and being especially aware of it if you are running any kind of monitoring over WAN links. You can still monitor your systems very effectively, even over high cost lines, with just a small amount of planning and a dose of common sense.