Switches form the foundations of your network and whilst they are generally stable bits of kit they can and do fail. When that happens, the impact can be dramatic, not only for your end-users, but also for core network functionality. Implementing a switch monitoring strategy is an important part of protecting yourself from the damage that can be caused when parts of your network go down.

Even though there is a huge amount of information out there about how to configure each individual aspect, it can be hard to know where to start. In this post, we’ll take you through the three steps you need to follow to start monitoring your switches.

Step 1: Configure SNMP for Secure Monitoring

First things first, this guide will assume that you are using managed switches which are already configured with IP addresses. Creating an IP address scheme is an enormous topic of its own which we’ll look at another day.

To get the most out of your hardware, you should now set up Simple Network Management Protocol (SNMP) to enable communication with your PRTG server. The SNMP is a widely used system for managing network devices which has been around since the late 1980s.

The two versions of SNMP in widespread use today are V2c and V3. To configure V2c, both the switch and the PRTG server use a shared “community string” which authorises the server to query the switch. V3 uses usernames and passwords to restrict access further.

SNMP V2c is still in use today because it is easy to configure and manage. However, it has one large disadvantage: all commands and responses are sent unencrypted. SNMP V3 addressed this problem by introducing authentication and encryption. However, the trade-off is a higher degree of complexity and management.

Ultimately, the choice of V2c or V3 is yours. We recommend that you use V3 for switch monitoring where possible. If you are using V2c, management traffic should be segmented by using a separate VLAN to ensure the unencrypted traffic cannot be “snooped” (segregating traffic like this is a good idea generally). Also, some vendors ship their switches with default community strings set (e.g. HP ship their Aruba switches with “public” as the community string). Regardless of your vendor, you should ensure that all default settings are changed.

You can use a variety of tools to test that your switches are configured correctly. Paessler SNMP Tester is a no-frills functional tool that does a great job and is available here.

Step 2: The Basics – Monitoring Overall Switch Health

Once your switches are set, it is time to configure your switch monitoring. There are three sensors that give you an immediate insight in to their overall health.

First up, the ever-important PING sensor. There are two reasons to always use a PING sensor:

1. A High PING time can be an early indication of a variety of problems. For example, you could have an unusually busy network, or the switch itself could be overloaded.
2. PRTG uses the PING sensor as a dependency for the other sensors on the switch. This means that if your switch goes down, you only receive one notification (from the PING sensor) rather than one notification for each sensor on the switch.

The PING sensor – start here and build up your switch monitoring.

Using PING in conjunction with sensors for CPU and memory usage is a powerful way to gain an overview of your switch health. For example, unusually high CPU and memory usage could indicate a DoS attack, perhaps where an attacker attempts to flood the forwarding/ARP table of your switches.

Once you have some data for each of your switches, you will be able to determine their “normal” levels. Using this information, you should start to set warning and error limits in PRTG to make sure you don’t miss a problem.

Step 3: Get Detailed – Traffic Monitoring

Once you have an overview for each of your switches, you can start to look in more detail. The most important thing you can do at this stage is to check your network documentation. Where does your network interface with the external environment? Which internal links are important? Are there devices that you rely on, and where are they patched into your network?

Add traffic sensors to each port that you identify. There are no set rules for which ports should be monitored but here are some general tips:

1. Make sure to set the sensor to alarm if you want to be notified when the link goes down. By default, traffic sensors will not trigger an alarm.
2. Only add a link once. For example, if two switches are connected to each other, only add one end of the link.
3. Don’t add sensors if you don’t need them. Stick to your list of important ports, or you will just end up using sensors needlessly.

In all likelihood, you will take a few goes to get this bit right. Some ports will immediately jump out as required, whereas some may not be so obvious. The amount of information you can build up about how your network functions is phenomenal. In fact, sometimes, you can end up with more data than you can use and end up removing unnecessary sensors.

Next Steps: Beyond Switch Monitoring

In any case, once you have completed the three steps above, you will have implemented a comprehensive switch monitoring strategy. Now you can sleep easier knowing that PRTG has an eye on your critical infrastructure.

This week’s blog kicks off a new series of posts looking at the how to put your devices and monitoring systems to best use. NetInf are network infrastructure and monitoring experts. We can help you with a huge range of projects so get in touch for a no-commitment chat about how we can work together.

Stay tuned for the rest of the series and sign up to our mailing list to receive a weekly roundup of everything we’re posting.