The Essentials Series - Part 1 - Solving Network Problems Before They Occur by Kelsey Burnes

The Essentials Series

Solving Network Problems Before They Occur sponsored by KNOW YOUR NETWORK

by Greg Shields

Article 1: How to Use SNMP in Network Problem Resolution .............................................................. 1 SNMP, the Solution .............................................................................................................................................. 1 SNMP, Total Network Awareness ................................................................................................................. 3 SNMP, Disaster Protection ............................................................................................................................... 4 SNMP, Easy Implementation .......................................................................................................................... 5 Article 2: How to Use WMI in Network Problem Resolution ................................................................ 6 The Network Rosetta Stone ............................................................................................................................ 6 WMI, Finger‐Pointer Preventer ..................................................................................................................... 8 WMI, Keeping Email Operational .............................................................................................................. 10 WMI, Network Monitoring for Servers and Applications ............................................................... 10 Article 3: How Effective Configuration Management Aids in Network Problem Resolution 11 Config Management, Little Problems with Big Impact ..................................................................... 12 Config Management, When the Fix Is Harder than the Problem ................................................. 13 Solving Network Problems Requires the Right Vision ..................................................................... 14

Copyright Statement © 2009 Realtime Publishers. All rights reserved. This site contains materials that have been created, developed, or commissioned by, and published with the permission of, Realtime Publishers (the “Materials”) and this site and any such Materials are protected by international copyright and trademark laws. THE MATERIALS ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. The Materials are subject to change without notice and do not represent a commitment on the part of Realtime Publishers or its web site sponsors. In no event shall Realtime Publishers or its web site sponsors be held liable for technical or editorial errors or omissions contained in the Materials, including without limitation, for any direct, indirect, incidental, special, exemplary or consequential damages whatsoever resulting from the use of any information contained in the Materials. The Materials (including but not limited to the text, images, audio, and/or video) may not be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any way, in whole or in part, except that one copy may be downloaded for your personal, noncommercial use on a single computer. In connection with such use, you may not modify or obscure any copyright or other proprietary notice. The Materials may contain trademarks, services marks and logos that are the property of third parties. You are not permitted to use these trademarks, services marks or logos without prior written consent of such third parties. Realtime Publishers and the Realtime Publishers logo are registered in the US Patent & Trademark Office. All other product or service names are the property of their respective owners. If you have any questions about these terms, or if you would like information about licensing materials from Realtime Publishers, please contact us via e-mail at info@realtimepublishers.com.

Article 1: How to Use SNMP in Network Problem Resolution I’ve spent almost 15 years of my life as an IT professional. In that time I’ve been a phone support operator, field technician, systems administrator, consultant, and now an independent technology author and presenter. Through those experiences, I’ve seen a wide range of very different environments in very different businesses. Those IT environments range from the exceptionally simple, installed into actual closets within small business offices, all the way to multi‐enterprise, multi‐national collaborative networks. What’s interesting about all of them is their similarity. Some networks have more applications than others. Some have faster connections between sites. Some use more remote applications. Yet there’s a common thread in all of them: from time to time, they all have problems. There’s also something remarkably strange about those networks I’ve seen. Even though we can all agree that every network occasionally has its problems, relatively few have the tools in place to find and fix them. For reasons of cost, or time, or lack of subject knowledge, many IT organizations haven’t implemented unified and comprehensive network monitoring solutions. It is my goal in this Essentials Series to explain why you should. With the right platform in place, you’ll experience less downtime, more customer satisfaction, and fewer late nights tracking down the network problems of the day. Using a series of examples from my own experience, I want to show you how effective network monitoring can help to solve network problems before they occur.

SNMP, the Solution Let’s start by looking at actual solutions to your network’s visibility problem. Networks are by nature very opaque. You can’t simply peer through cables or into routers to see the behaviors going on during their operation. To see what’s going on in your network, you need tools that do the peering for you.

Those tools start with the individual devices themselves. For example, if you queried the interface statistics on a Cisco router, you would be greeted with information about that interface’s traffic: router1#show int Ethernet0 is up, line protocol is up […snip…] 37592 packets input, 2859273 bytes, 0 no buffer Received 15938 broadcasts, 0 runts, 0 giants 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 input packets with dribble condition detected 15288 packets output, 1395393 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets, 0 restarts 0 output buffer failures, 0 output buffers swapped out

That information is descriptive of the individual device you’ve logged into, but stops there. Today’s network devices natively include all the necessary capabilities to gather and report on their network traffic statistics. You can today request this information from each device and manually build a picture of how your network is operating. However, the complexity of doing so rises dramatically as your network’s count of interconnected devices goes much past one. To combat these complexities, the Simple Network Management Protocol (SNMP) was ratified in the early 1990s. This protocol enables a request‐response framework between individual devices and a central Network Management Solution (NMS). Individual devices can be polled for their information through a GET request by the NMS. Device information is stored and can be addressed via its globally‐unique Management Information Base (MIB) Object Identifier (OID). An OID’s long string of digits represents the “address” for the unit of information being stored on that device. Information being stored can relate to network statistics, details about that device’s configuration, performance and throughput metrics, or really any information that the device’s manufacturer has enabled. This part of SNMP’s poll‐based nature means that information must be requested if it is to be sent back to the NMS. For this reason, SNMP also has a unidirectional alert component. An SNMP “trap” represents a preconfigured alert from a device back to its NMS, reporting on conditions that the NMS should know about. This setup enables SNMP clients to rapidly notify the NMS when problems exist. SNMP also comes in many versions, with later versions including additional and desired features over those in the previous. SNMP v3 is today’s version commonly used by most environments because it adds a suite of critical security features that protect its data in transit and authenticates servers prior to communication. This encryption ensures that the clear text data transfers of earlier versions are protected from prying eyes, while servers must prove their identity before they’re communicated with.

You’ll probably recognize that this information on SNMP is neither new nor revolutionary in the way it works. With SNMP rapidly approaching its 20th birthday, its protocol is mature and its capabilities are well known. Yet in making this statement, why are so many IT organizations still not using it? Perhaps they don’t understand its true power in solving network problems before they occur. Consider a few examples…

SNMP, Total Network Awareness Recognizing how SNMP does its job is far less exciting than realizing how it can spot and solve network problems. The information gained through SNMP connections and stored in a central NMS enables a situational awareness of your network. This awareness illuminates the behaviors on all devices through a single console, providing you a single heads‐up display of your network’s health. As an example of this, I used to work for a company that built satellite ground stations. This company’s complex development activity required the cooperation of multiple business units and even multiple companies, all in different locations. To ensure that everyone was working on the same page, we architected a centralized collaboration environment that brought all parties together to the same set of applications. This remote application infrastructure was a perfect solution for its users, enabling them to share documents and work together whether they were in Colorado, California, Massachusetts, or anywhere. Perfect, that is, until the network began experiencing problems. Remote application infrastructures, such as Microsoft Terminal Services or Citrix XenApp, by nature perform well over low‐bandwidth connections. They enable users to work on remote applications as if they were installed locally, even over the slowest of network lines. Yet although they do well in low‐bandwidth situations, the streaming nature of their protocols means they do not do well across those that are highly latent. In this environment, it was well known that certain WAN connections to certain sites would experience latency from time to time. This project’s network traffic was only a portion of the traffic sourcing from each site. Rather than waiting for administrators to get phone calls when users’ experience degraded, this environment elected instead to configure SNMP across each remote device. Each device was configured to report to a central NMS. That NMS queried each device for its interface utilization and ping latency statistics on a regular basis. Traps and subsequent administrator alerts were additionally set up to alert the central NMS when metrics went below acceptable thresholds.

Figure 1: SNMP enables the creation of ping latency graphs across multiple devices. The result was the creation of a real‐time graph similar to that shown in Figure 1. There, you can see where ping latency information across devices was graphed, giving administrators information about the health of each connection. Because the right people were also alerted as conditions went below thresholds, they were able to compensate as necessary to maintain their users’ experience.

SNMP, Disaster Protection Although SNMP is most commonly associated with gathering network statistics and configurations, it is extensible to even non‐network devices as well. SNMP was originally developed as a communications framework between all kinds of networked devices. Thus, any device with a network connection can potentially receive and respond to SNMP requests or send its own traps. Nowhere is this more valuable than with the environmental sensors used in many data centers today. These environmental sensors regularly check the temperature, humidity, and (in the case of accidental flooding) water level present in the data center room. The installation and use of these sensors is critical to ensuring that your expensive IT investment doesn’t melt down if your data center air conditioning stops functioning.

That exact situation happened to me at another former client. That day, I had the lucky privilege of stepping into their data center on the very day their air conditioning unit experienced a massive, yet unnoticed, failure. Walking into that data center, the massive outpouring of heat made me immediately recognize that something was terribly wrong. I looked over to the room’s temperature sensor—a cheap model more often found attached to the outside of your bedroom window—to discover that the temperature had crossed the 80° threshold and was increasing at a rate of 1° every 10 minutes. Humidity was similarly affected. Although the problem was quickly resolved through the forced shutdown of non‐essential equipment and the introduction of backup air conditioning, the problem could have been dramatically worse had my timing been different. The network‐enabling of data center sensors using protocols such as SNMP illuminates another of this protocol’s key value propositions. With the right tools in place, an alert could have notified administrators immediately when temperature conditions in the data center started their deviation. Consolidating SNMP’s data into a unified network management solution enables the real‐time alerting of problems directly to network administrators.

SNMP, Easy Implementation As I travel across IT environments, I find that a common hurdle in implementing comprehensive monitoring relates to its perceived difficulty in implementation. Although numerous enterprise‐scale monitoring solutions are available today, their implementation often installs little more than an empty shell to be later populated by dedicated monitoring administrators. Needed for environments that aren’t necessarily “enterprise” are cost‐effective solutions that implement quickly and without the need for specialized knowledge. The right solutions for your environment will immediately begin gathering useful data with a minimum of daily maintenance. As you’ll discover in the next article of this series, such solutions integrate with servers and applications as well as networking devices to provide a complete view into your network.

Article 2: How to Use WMI in Network Problem Resolution I’ve found myself constantly amazed at the language barrier we experience in the world of IT. I’m not talking here about the barrier between the technologists and the non‐ technologists, the geek and non‐geek. I’m speaking about the language barrier we’ve all experienced between an organization’s “server” administrators and their “network” administrators. You’ve probably been in the same situation as you’ve been called in to work together on a big problem. Your network team sits at one side of the conference table, while the server admins take over the other. Although some problem is preventing your users from getting their job done, the two opposing teams pull out domain‐specific vocabulary the other doesn’t understand in an effort to prove that the problem isn’t their fault. This circle‐the‐wagons approach to solving IT problems has been around as long as the problems themselves. When a major problem occurs in the environment, a common approach is to gather everyone that is potentially involved and focus them on today’s firefight. Yet solving problems in this way is expensive in terms of people’s time and in cost to your business. There’s got to be a better way.

The Network Rosetta Stone With the right Network Management Solution (NMS) solution in place, it is possible to improve your resolution of large‐scale problems without the finger pointing. The right solutions leverage integration to servers and applications as well as network components to provide complete visibility into your operating environment. The result is that your NMS becomes a kind of Rosetta Stone or universal translation device between IT teams; the NMS helps the network team understand the impact of servers and applications, while giving systems administrators a perspective on the network infrastructure. One way in which an NMS, acting as a Rosetta Stone, translates your Microsoft Windows computers is through Windows Management Instrumentation (WMI) integration. Microsoft’s WMI is a platform‐specific service that enables third‐party devices to query the Microsoft OS for details about its behaviors. As a rough analogy, if you consider the Simple Network Management Protocol (SNMP) the request/response tool for network device monitoring, WMI performs the same actions within the Windows OS. A typical WMI query might look like this: Select FreeSpace from Win32_LogicalDisk

In this query, the targeted machine is asked to provide the amount of free space on its installed volumes. This process looks different than SNMP’s numerical Object Identifier (OID) approach, but the result is the same. An NMS queries for information across multiple Windows machines, storing the results into its local database and reporting them along its management consoles. Because multiple Windows machines can be queried by a central monitoring server, that server becomes the locus of analysis for behaviors across servers and network devices (see Figure 1). As a result, it becomes dramatically easier to locate or prevent network problems because their root cause can be tracked to very specific endpoints and behaviors.

Figure 1: A unified dashboard that displays information about servers, applications, and network devices in one place.

WMI, Finger‐Pointer Preventer It is the intersection of WMI and SNMP monitoring where an NMS provides great value. It also helps out with the historical problem of teams pointing fingers at each other. Consider another situation I experienced not long ago with one of my consulting clients. At this client, a particular Windows virtual machine was experiencing an intermittent problem with its network connection. That network problem would occur only irregularly; however, when it did occur, it impacted a large number of users. Thus, resolving this problem was extremely important for this client. The client was very focused on the perceived network source for this problem, pointing their attention and resources to the network and its behaviors. “There must be something wrong with the network cards, their drivers, or their firmware,” they would tell me. Yet what they did not recognize was how virtualization tends to significantly increase the complexity of troubleshooting these types of problems. With multiple virtual machines co‐ located atop a single virtual host, a simple network problem’s root cause can be something as seemingly‐unrelated as a shortage of system memory or too much consumption of processor cycles. To resolve the situation, a unified NMS was implemented that enabled the collection and reporting on metrics through SNMP and WMI statistics. This same solution integrated with the virtualization platform to provide additional data about its processing as well (see Figure 2). The solution to the problem was immediately discovered the very next time it occurred. WMI queries to the virtual host discovered that the virtual host’s processor utilization experienced a dramatic spike in use at the very moment the networking problem occurred. The solution was to offload some of that virtual host’s workload to other servers to prevent the resource‐overuse situation.

Figure 2: A single view with SNMP, WMI, and even virtualization counters provides a holistic view of the entire environment.

WMI, Keeping Email Operational Another averted crisis that may strike home in your own network environment has to do with keeping email servers up and running. Although most businesses can endure the loss of file servers for a day, or even a few databases for a few hours, the loss of the email system usually sends a business’ executives into orbit. That’s why in organizations both large and small, the email system is often considered one of the most important services to remain up and operational. Email at the same time can be one of the most dynamic data processing systems in your data center. Handling thousands of messages a day in even the smallest of environments, email systems must effortlessly deal with large attachments, malware, and addressing failures while preserving the users’ experience within their desktop email clients. I was once called in to architect a monitoring solution for a company in the financial services industry. Although this client needed the monitoring solution for their entire multi‐site infrastructure, the real reason for its implementation was due to regular and painful problems with the email server. Implementing the right kind of tools for this small business of less than 100 employees was a trivial installation. Connecting it to network devices, identified servers, and even a few clients was not difficult because the system included preconfigured templates for each type of device. We completed the installation and initial configuration in less than a day. The next morning, I returned to the client to find an extremely tired but extremely happy systems administrator sitting at his desk. It turns out that the majority of the problems with the email system were related to users overfilling it with data to the point where it would consume all its available disk space. That very night after the installation of this monitoring system, the administrator received an alert notifying him that the email server’s disk drive was within a few percentage points of full consumption. Unlike in each of the previous incidents, this administrator was able to add the necessary disk space prior to the email server’s database shutting down. The right level of monitoring across network, server, and even application facets of the IT environment prevented the problem from ever occurring.

WMI, Network Monitoring for Servers and Applications As with the previous article in this series, these stories are told to explain why effective monitoring goes far in preventing problems. With the right monitoring that spans every part of an IT environment, you gain much‐needed visibility into areas where you otherwise would have none. By integrating the network focus traditionally associated with SNMP with the server and application focus commonly used with WMI, that vision spans the entire environment. In the end, it may bring your network and server teams closer together as a cohesive unit for better managing your IT infrastructure.

Article 3: How Effective Configuration Management Aids in Network Problem Resolution The third focus of this Essentials Series is on the need for effective configuration management, a common feature across many Network Management Solutions (NMSs) but one that sometimes gets missed. In this instance, what do I mean by configuration management? I mean the unified storage and uniform distribution of configurations to each of the devices on your network. There is a certain brilliance in the way that most network devices can and are configured. Using little more than text files, a smart administrator can set up their interfaces, ACLs, and essentially every other setting within these devices. Their use of text files means that one device’s configuration can very easily be replicated on another device through a file copy. Their editing is also trivial, accomplished with a simple text editor or SSH application. As an example, the following code snippet shows the simplicity of a Cisco device’s initial configuration: no service password‐encryption ! hostname Router ! enable secret 5 $2m$FJdHx53V$t7rQJop3jjbXIB7n3 ! interface FastEthernet0/0 ip address 192.168.1.1 255.255.255.0 duplex auto speed auto ! interface FastEthernet0/1 no ip address duplex auto speed auto shutdown ! interface Vlan1 no ip address shutdown

Yet there’s a certain level of pain that comes with this simplicity. That pain grows as the number of devices and their individual configurations increases in number. Managing the configuration of just a few devices means that you’re responsible for just a few text files and their individual settings. But as your network grows in size and complexity, your number of elements under management grows geometrically. At some point, no one person can safely handle the sheer volume of text files and their settings that are required by a production network. It is in just this situation where the configuration management elements of an effective NMS grow extremely valuable to the IT organization. An effective NMS will include the database storage of configurations, versioning and version control of individual config files, analysis tools for comparing those files, and the ability to rapidly deploy changes to devices all across the network. In much the same way that most people program their favorite phone numbers into their cellular phones, managing a network through an NMS ensures you don’t accidentally call the wrong person, forget a phone number, or misconfigure a device in such a way that brings down the LAN.

Config Management, Little Problems with Big Impact This workflow wraps around the traditional actions associated with changing a device config and adds a lot of value to the process. Consider a situation I experienced a number of years ago in the network of a major governmental defense contractor. There, a network condition began occurring where some servers intermittently lost their connection with the network. When those servers could talk to the network, their connection speeds were dramatically lower than expected. Network bandwidth rates were so slow that network applications began to suffer, users began calling into the Help desk, and fellow administrators started contacting loved ones to report they’d be spending the night. In this situation, the entire staff of systems administrators was tasked with resolving the problem. As the problem affected a large percentage of servers on the network, every eye was needed on the problem. After a full day of troubleshooting by the entire staff, the problem was eventually tracked to an incorrect configuration on a particular switch in the data center. That configuration mismatched the duplex settings between the switch and its connected servers, with one side inexplicably reset to 100/Half duplex with the other at Auto/Auto. As a result, the two sides found themselves repeatedly renegotiating their communication channel, with the resulting loss in service and performance. In the end, a half‐dozen systems administrators lost a full day of productive work as a result of a very simple misconfiguration. This misconfiguration was set into place by a well‐ meaning network engineer, who manually made a small change to a config file and accidentally introduced the error. Because the engineer completed the change using a traditional SSH connection directly to the device, the change wasn’t logged into any change management system. No one knew about the change, and so no one was looking in that location for the problem. Conversely, had the engineer made the change using an NMS’ change control engine, the error would have been found before it was released into production.

Config Management, When the Fix Is Harder than the Problem Another story that is relatively common with network engineers involves an enterprise client of mine and their massively distributed network. This client was a single business unit of a much larger corporate network, responsible for the network traffic for many thousands of people across dozens of sites. As you can imagine, the level of networking equipment required to support the infrastructure was large and exceedingly complex. This client and I were working on a widespread network slowdown situation. This situation was not necessarily that the network had gotten slow, or for some reason stopped operating at its expected level. In this environment, the network was slow, had been slow, and its users had grown to accept its slowness as baseline. The network engineer and I recognized that its baseline performance simply did not make sense based on the kinds of equipment in the infrastructure and the bandwidth rates between sites. In this environment, even the intra‐LAN traffic itself was slow beyond comprehension. After a substantial amount of time peering through reports and looking through device statistics, we realized that a small but important misconfiguration had been propagated into the config files of each and every device on the network and across every site. The specific misconfiguration is less important than the realization that the scope of the fix was far greater than our group of individuals could take on. With literally thousands of devices spanning dozens of sites, the steps needed to locate each device, log in, make and confirm the change, and move on to the next device was anticipated to take between 5 and 10 minutes per device. Multiplying that number across each device meant that the solution could take literally months of constant manual effort to resolve. Adding to the complexity of the resolution was the nature of the fix itself. Due to the specific change required, a rapid fix was necessary to preserve network connections between sites. Although the fix was trivial, the network engineers were baffled as to how to implement it. The solution arrived with the implementation of an NMS not unlike those discussed in this Essentials Series. By adding the NMS to the environment and instructing it to automatically discover and map the network infrastructure (see Figure 1), the organization was able to very quickly bring each individual device under centralized management. Using the NMS solution’s bulk change feature enabled the team to quickly implement and distribute the change across the infrastructure. The result was a massive improvement in performance across the business unit, and a promotion for the engineer.

Figure 1: An NMS’ automated discovery and mapping features can quickly bring a large network infrastructure under management.

Solving Network Problems Requires the Right Vision As stated earlier, the goal of this Essentials Series has been to illustrate why effective monitoring and management is necessary for a healthy network. That need is the case irrespective of the size of your network. Whether you’re a small business with a few devices or a large enterprise with many thousands, not having this vision prevents you from actually understanding what’s going on inside your network. As this article has shown, not having these tools also inhibits you from cohesively managing the configuration of your network devices when you need them the most. When looking for an NMS, look for one that is scoped to the needs of your environment, with the right features and integrations you require for a complete situational awareness across the IT landscape.