Chapter 8

Network Monitoring

The Network Monitoring feature for System Center 2012 Operations Manager was one of the most hyped and eagerly awaited components of the newly released product, and it definitely lives up to expectations!

This chapter explores the various features that accompany Operations Manager’s network monitoring. We will explain network discovery and how you can manage your network devices once you have discovered them. Collecting data on your network devices (or any component in your environment) is one thing, but it’s what you do with that data after it has been collected that is most important. We also discuss the various reporting options related to network monitoring that are available to you. Once you have a handle on these options, we will delve into the tasks, groups, and dashboards that combine to give you a powerful insight into your network device environment. Finally, we will discuss common troubleshooting issues and their solutions, which will help you to become proficient with this aspect of Operations Manager.

In this chapter, you will learn to:

  • Explore network monitoring
  • Discover network devices
  • Manage network monitoring
  • Use network monitoring dashboards
  • Troubleshoot network monitoring issues

Exploring Operations Manager Network Monitoring

Having a holistic view of all the components across the IT estate that you are responsible for is essential when you need to quickly identify critical service and application failures. The Network Monitoring feature of Operations Manager delivers this transparency and allows you to identify issues that originate at the physical network layer—which forms a crucial piece of your business service. This functionality, combined with the typical Operations Manager application and operating system monitoring, provides the full solution to managing your IT as a Service (ITaaS).

Let’s look at an example. In the Operations Manager console, you receive an alert telling you that a critical Windows server is unavailable. With Operations Manager network monitoring configured, you would also see an alert informing you that a physical network device port is offline. When you view the Network Vicinity Dashboard for the Windows server, you see that the unavailable server is connected to the offline port on the network device. This overall picture of your environment then expedites problem resolution because you can focus quickly on the actual network port that is offline as opposed to the “false positive” alert that the Windows server is at fault.

In this section we explore in detail the various components of the Network Monitoring feature of Operations Manager. Understanding these features will give you the full picture of the power and benefits that network device monitoring can bring you.

With the 2012 release of Operations Manager, you now have the following at your disposal:

  • Multivendor support
  • Multidevice support
  • Multiprotocol support
  • Resource pools
  • Network dashboards
  • Network reports

Multivendor Support

Operations Manager lets you discover and monitor a wide range of vendor network devices. It monitors any network device that supports the Simple Network Management Protocol, or SNMP (multiprotocol support is discussed later in this chapter in more detail) and also provides extended monitoring for devices that implement the management information base (MIB) RFC 2863 and MIB-II RFC 1213 standards.

Microsoft has published an Excel spreadsheet with a list of network devices that support the extended monitoring capability of Operations Manager. As of this writing the list contains more than 800 devices, based on Object ID (OID), device type, vendor, model name, and whether or not the processor and memory were monitored as part of the extended monitoring function. Figure 8.1 shows the Excel spreadsheet and a sample of devices in the list. You can download the entire list here:

Figure 8.1 Certified device list for Operations Manager

image

www.microsoft.com/download/en/details.aspx?displaylang=en&id=26831

If you find that the device you are looking for is not listed in the spreadsheet, don’t worry, because Microsoft plans to update the list in future Operations Manager Cumulative Updates (CUs). On the spreadsheet you can see what level of monitoring you can expect from your device. The level of information that you are going to see is dependent on the MIB that Microsoft has used in the discovery. If your device is on the list, then it will be “certified,” which means that some level of detailed monitoring will take place that can include information on the processor, memory, and chassis.

If your device is not on the list, it will be added as a “generic” network device, and the interface that it was discovered on will simply perform an availability poll to give a health status back to the console. This is the same basic level of monitoring available out of the box from Operations Manager 2007 and is essentially an “up or down” scenario with no deep information on the device components.

Multidevice Support

Operations Manager can monitor physical network routers and switches, including the interfaces and ports on those devices. Virtual local area networks (VLANs) and Hot Standby Router Protocol (HSRP) groups in which discovered network devices participate are also monitored. Firewalls and load balancers are fully supported for discovery and monitoring too.

As you learned in Chapter 1, “Overview of Operations Management,” Microsoft has designed the System Center 2012 suite to fully integrate into the private cloud model. For this reason, it is important that Operations Manager be able to discover and monitor components like load balancers to enable you to monitor the fabric that supports cloud-based applications.

Multiprotocol Support

Operations Manager can discover and monitor network devices that use three different versions of SNMP: SNMP v1, v2c, and v3. Along with the standard support for Internet Protocol Version 4 (IPv4) network devices, Operations Manager now provides Internet Protocol Version 6 (IPv6) discovery when running recursive discoveries.

Resource Pools

When two or more management servers are added to an Operations Manager management group, these management servers become part of a resource pool, and all monitoring data is distributed to each member of the pool.

So, how does this apply to monitoring of your network devices? In Operations Manager 2007 the best practice was to perform all network monitoring on a separate management server. If that management server went down (or if the health service just stopped), you lost your network health. With resource pools, you can add management servers to a pool and assign your network devices to be monitored by the pool. If one management server in that pool fails, another one will automatically take over the monitoring.

When you use resource pools, not only are you able to select the management servers that will be involved in network monitoring, but you also are able to omit other management servers. This granularity leaves the power in your hands to decide which management servers perform network monitoring and which ones don’t, even if they are already members of another resource pool.

Dashboards and Reports

Out of the box, Operations Manager provides you with a number of new dashboards specifically designed for network monitoring. These dashboards display data on instance details, average response times, vicinity views, and average availability. The dashboard views allow you to quickly understand your network on a number of levels and enable you to look at a holistic map of devices such as switches, routers, servers, and also the Windows Server devices that are physically connected to them.

Network Monitoring reports focus on the interfaces, memory, and CPU of your devices. There are three interface reports that cover traffic volume, packet analysis, and error packet analysis. The other two reports cover CPU and memory utilization. We discuss Network Monitoring dashboards and reporting in greater detail a little later in this chapter.

The Operations Manager Network Monitoring Journey
Network monitoring is nothing new to Operations Manager. In Operations Manager 2007 you had the ability to discover a network device and determine whether that device was available. Unfortunately, the monitoring stopped there, and so did its usefulness. It was so poor, in fact, that no one really used the standard out-of-box monitoring. As a result, vendors and the System Center community started to write management packs (MPs) and connectors to enhance network device monitoring.
At this point it is helpful to get some background into Operations Manager 2007 and the network monitoring journey we have been on. In Operations Manager 2007 you could discover a network device but only a single interface on the device and that was it. This was just about sufficient for a device with a single interface like a UPS, but what if you wanted to discover a router or switch?
Up stepped the System Center community and we got the SNMP Extensions from Raphael Burri and later the xSNMP MP from Kristopher Bash. The xSNMP MP was so good, the Operations Manager product team employed Kris, but his MP only covered popular devices from popular vendors. All of this community-driven effort was still hampered by the fact that the SNMP stack used in Operations Manager 2007 was just not up to the job. Once you started to scale, you reached performance issues quickly. You were also limited to SNMP v1 and v2, and although you got better insights into the network it was a poor second compared to other network monitoring tools available to the market.
Getting SMART about Network Monitoring
There came a point in time when Microsoft IT had to use Operations Manager for its own internal monitoring. When they deployed Operations Manager 2007 they wanted to integrate network monitoring into their monitoring capability. They evaluated and chose the EMC Solutions for Microsoft System Center Operations Manager connector product. This connector was a third-party add-on and was built on SMARTS technology, which was originally acquired and then developed by EMC (it’s now called Ionix). Microsoft IT was so impressed with this technology, they began negotiations to license some of the network management components of EMC SMARTS and have now built these components into the core 2012 Operations Manager product.

Understanding Network Device Discovery

Before you can manage and monitor your network devices, you need to first get them discovered and available through the Operations console. This section will discuss the different concepts and requirements of Operations Manager network device discovery.

Discovery Rules

To enable network device discovery, you have to create discovery rules within the Operations Manager console. When you create a discovery rule, you need to assign a specific management server or gateway server to run that particular rule. This is because only one discovery rule can be run per management server or gateway server. You might need to design the placement of your management servers to operate on different network segments to ensure that they can communicate with the network devices that they will be discovering.

You can choose to run the discovery rules automatically on a schedule or just run them on demand manually when you need to. A discovery rule can be configured to run either as an explicit discovery or as a recursive discovery:

Explicit Network Discovery When you configure a discovery rule to run as an explicit network discovery, it will only attempt to discover those devices that you explicitly specify in the wizard by their IP address or fully qualified domain name (FQDN). Once a device can be successfully accessed, monitoring will be enabled for it and there will be no monitoring available for any devices that cannot be successfully accessed. The rule can be configured to discover and access devices using either Internet Control Message Protocol (ICMP) or SNMP. It can also be configured to attempt to use both protocols as part of its discovery mechanism if desired.
Recursive Network Discovery This type of discovery allows for a network scan and will initially attempt to discover devices that you have explicitly specified. It will then attempt to discover any other network devices that it knows about through its Address Routing Protocol (ARP) table, its IP address table, or the topology MIB to grow the network map and present all applicable devices to you for monitoring.
Like the explicit discovery rule, recursive discovery can also be configured to discover and access devices using ICMP, SNMP, or both. IPv6 addresses can also be identified; however, the initial device that is discovered must use an IPv4 address.
With recursive discovery, you can create a filter by using properties such as the device type, name, and object identifier (OID) to give more control over what is or isn’t discovered.

Any combination of SNMP v1, v2, and v3 devices can be discovered by a single discovery rule. However, SNMP v3 devices can only be discovered by explicit discovery or by being explicitly specified in a recursive discovery rule.

With a recursive discovery, if you specify an SNMP v3 device, then only that device will be discovered but not any other devices that are connected to it. Likewise, if you specify an SNMP v1 or SNMP v2 device within a recursive discovery, then the rule will only discover SNMP v1 and v2 devices and not SNMP v3 ones.

Explicit vs. Recursive Discoveries
A discovery rule can only perform one or the other of an explicit or recursive discovery and cannot perform a combination of them. In general, you should use explicit discovery because it is most likely that you already know all the network devices that you will want to have discovered.
The Recursive Discovery option can put unnecessary load on your management servers in large network environments by discovering devices that ordinarily you have no requirement to monitor and manage. If you are going to use recursive discovery, you shouldn’t run it more than twice a week. Most networks will already be well mapped out and well known and wouldn’t have a lot of new network devices being added on a frequent basis, so twice a week is more than adequate.

RunAs Accounts

During any type of discovery in Operations Manager, credentials are required to ensure that the relevant access and security policies are being adhered to. In the Network Monitoring feature, these credentials are managed through RunAs accounts that supply the community string (for SNMP v1 and v2 devices) or access credentials (SNMP v3) so as to perform the security negotiation between the Operations Manager management server and the network device. The SNMP community string value is another term for a password that will be used to carry out the security negotiation.

The RunAs account community string (for SNMP v1 and v2) can be configured on the network device as either a read-only or read-write string to enable a granular security model throughout your network monitoring.

For SNMP v3 network devices, you must configure a unique RunAs account with the following credentials:

Username This will need to be obtained from the device configuration.
Context A name that, together with the username, determines the access permissions of a request sent to the SNMPv3 agent.
Authentication Protocol Choose one from MD5 for Message Digest 5, SHA for Secure Hash Algorithm, or NONE.
Authentication Key String consisting of 1 to 64 characters; this will be required if the authentication protocol is MD5 or SHA.
Privacy Protocol Choose one of DES for Data Encryption Standard, AES for Advanced Encryption Standard, or NONE.
Privacy Key String consisting of 1 to 64 characters; required if the privacy protocol is DES or AES.

RunAs Profiles

When you first install Operations Manager, two new RunAs profiles are automatically created that are used for network monitoring. These profiles are defined as:

SNMP Monitoring Account This account is used for SNMPv1 and SNMPv2 monitoring.
SNMPv3 Monitoring Account This account is used for SNMPv3 monitoring.

The RunAs accounts that you create or specify for network device discovery are automatically associated with the appropriate SNMP Monitoring RunAs profile.

Discovery Phases

There are three phases of Operations Manager network discovery. These phases take into account the initial discovery, the validation of data returned, and then the network interface correlation. Each running phase is displayed in the status of the discovery rule within the Operations Manager console:

Probing In this phase, the management server attempts to contact a device using the specified protocol (ICMP, SNMP, or both) and uses the following methods:
ICMP Only Successful discovery only if it can ping the device
SNMP only Successful discovery only if it can process an SNMP GET message
ICMP and SNMP Successful discovery only if it can contact the device using both protocols
Processing Once the Probing phase completes, Operations Manager processes all of the information returned from the device and maps out its components such as ports and interfaces, memory, processors, VLAN membership, and HSRP groups.
Postprocessing For this final phase, Operations Manager correlates the network device ports to the servers that the ports are connected to, inserts all relevant items into the operational database, and associates RunAs accounts to each of the network devices.

When the three phases have completed and discovery is finished, the resource pool that you have specified in the discovery rule configuration begins monitoring of the discovered network devices.

Windows Computers Running SNMP
So what happens when you run a recursive discovery and you have Windows computers already configured and running the SNMP service on your network? Will these computers show up as network devices in Operations Manager?
The quick and easy answer to these questions is: No!
The reason for this is that Windows computers running SNMP are automatically filtered out of discovery results when the following conditions are met:
  • The device type is Host and the vendor is Microsoft
  • The sysDescription field contains Microsoft
  • The sysOid starts with .1.3.6.1.4.1.311.1.1.3.1
  • The sysOid contains 1.3.6.1.4.1.199.1.1.3.11

Configuring Network Device Discovery

The discovery process is the most important administrative effort required to implement network monitoring. This section will walk you through the steps required to configure network device discovery for your environment.

Before you begin your network device discovery, make sure that you have configured all firewalls between your network devices and Operations Manager management servers (including the Windows Firewall on the management server itself) to allow SNMP (UDP) and ICMP bidirectional communication along with ports 161 and 162.

The following steps walk you through the process of adding network devices to your Operations Manager environment:

1. In the Operations Manager console, select the Administration tab and then expand Administration ⇒ Network Management view.
2. Right-click on Network Management and select the Discovery Wizard option to start the Computer and Device Management Wizard, as shown in Figure 8.2.

Figure 8.2 Computer and Device Management Wizard

image
3. Once the wizard begins, select Network Devices and then click Next.
4. Enter a name and a description for the discovery rule, select the management server or gateway server that is going to run the discovery, and then choose a resource pool. Figure 8.3 shows an example of this screen. Click Next when you have added the relevant information to move on.

Figure 8.3 Network Devices Discovery Wizard, General Properties

image
Network Monitoring Resource Pool Recommendations
At this point you may ask what is considered best practice for network monitoring resource pools. If you have a large number of network devices to be monitored, it is good practice to deploy specific management servers just for network monitoring, and these management servers will become members of a new custom resource pool group. If you use a custom resource pool group, it will also prevent other management servers from doing any network monitoring and as such enable segmentation of this aspect of monitoring within your environment.
To ensure your network monitoring scales out properly, be aware that Operations Manager supports monitoring the following number of network devices and ports:
  • 2,000 network devices (25,000 monitored ports approximately) managed by two resource pools
  • 1,000 network devices (12,500 monitored ports approximately) managed by a resource pool that has three or more management servers
  • 500 network devices (6,250 monitored ports approximately) managed by a resource pool that has two or more gateway servers
5. When you arrive at the Discovery Method screen, you are presented with two options, as shown in Figure 8.4—Explicit discovery and Recursive discovery.

Figure 8.4 Choosing a discovery type

image
Once you have made your selection, click Next to continue.
6. On the Default Accounts screen, you can create a new RunAs account or use an existing one. If you use different SNMP community strings on different network devices, you would need to create different RunAs accounts for each community string. Figure 8.5 shows an example of multiple RunAs accounts being selected for a network discovery.

Figure 8.5 Using multiple RunAs accounts

image
Once you have configured and selected your RunAs accounts, click Next to move on.
7. On the Devices screen, click the Add button to specify your device information. In the Add A Device window, enter the name or IP address of your network device; select your access mode, SNMP version, RunAs account, and TCP port number; and then click OK.
ICMP and SNMP Discovery Options
When you are configuring network discovery for any specific device, it’s possible to change the access mode—by default it’s both ICMP and SNMP—and if you leave this option selected, then both access types must succeed before proceeding. If ICMP can’t ping the device or SNMP can’t connect, then the discovery fails. Be aware of this if you have an internal firewall policy that blocks ICMP (PING) traffic.
You can change the SNMP version from v1 or v2 to v3 and change the RunAs account and port number. If you are unsure as to what port you should use (SNMP defaults to 161), you can either telnet the port or look at the management page for the device. Repeat this process for each device that you want to add, and fill in the rest of the options.
It’s also worth noting here that if you have a large number of devices that you want to explicitly add all at once, you can specify a text file with a list and Operations Manager will import them all—nice and easy! Figure 8.6 shows an example of a large number of devices imported using the text file method. The text file should have a single IP address on each line. Once you’re happy with your selections, click Next to continue.

Figure 8.6 Specifying devices to discover

image
8. On the Include Filters screen (applicable only if you selected Recursive discovery earlier), you can choose whether you want to discover all devices that are connected to the network or just look for devices within a specific IP range. If you want to filter for specific ranges, you can also specify exactly what type of device is to be imported. Once the device is supported for the extended monitoring configuration as per the list on the released Excel spreadsheet mentioned earlier, you can then specify a filter of devices that includes bridges, routers, firewalls, load balancers, and so on. Figure 8.7 shows the Add Filter dialog box that allows you to modify this. Click Next to move on once you have decided on the subnets you want to discover.

Figure 8.7 Add Filter dialog box

image
9. On the Exclude Filters screen (applicable only if you selected Recursive discovery earlier), you can specify the IP addresses that you do not want discovered as part of this task. Click Next once you are finished here to continue.
10. Once you arrive at Schedule Discovery, you can configure how often you want to perform the discovery. As in Figure 8.8, you can choose a time of the day, what days of the week you want the discovery to run, or whether you just want to run the discovery manually whenever you need it.

Figure 8.8 Scheduling the network discovery

image
Click Next to move on when you’re ready.
11. The penultimate screen in the wizard is Summary. Confirm all of your settings are correct; then click the Save button to save the new discovery.
12. Once the discovery is saved, you will be presented with the final Completion screen that confirms the discovery has been created successfully. Leave the check box for the “Run the network discovery rule after the wizard is closed” option enabled and then click the Close button to finish the wizard and to automatically kick off your new discovery to find the devices you want on your network. Discovery of a large number of network devices can take several hours to complete, so ensure you have given enough time before moving on to the next step in this process.
13. To confirm your devices have been discovered correctly, from the console select the Monitoring tab and then navigate to and expand the Network Monitoring folder. Click the Network Devices view, and the devices you have just discovered will display in the central screen. As Figure 8.9 shows, right away you can see the health state, name, model, SNMP address, and even the vendor description. This confirms and completes your network device discovery within Operations Manager.

Figure 8.9 Network Devices view

image
Network Device Discovery Failure
When you’re running your network discovery rules, it’s not uncommon to have a device or number of devices fail to be discovered. This can become a headache if you don’t know where to look for a list of these failed devices and you really don’t want to have to trawl through all of the discovered devices in the console and manually compare them against your own spreadsheet or text file that contains the full list of everything that should be discovered.
In this instance, the failed device or devices will be listed at the following location within the Operations Manager console: Administration pane ⇒ Network Management ⇒ Network Devices Pending Management.
Once you have located all of your failed devices, you can use one of these options to try to rediscover them again:
  • Right-click the failed device from within the Network Devices Pending Management view and then click Submit Rediscovery.
  • Rerun the discovery rule again by right-clicking the rule and selecting the Run option from Administration pane ⇒ Network Management ⇒ Discovery Rules.

Network Device Descriptions

The name that the device is displayed as cannot be changed afterward. If you have a large number of network devices or are even planning the deployment of any new devices into your network, you should spend some time mapping out and configuring the device names and locations so that when you view them within Operations Manager, they have a meaningful description to you.

So, how does Operations Manager choose the name to display for your device? It uses a naming algorithm where it attempts DNS resolution from the following sources, and the first one of them to succeed becomes the name of the device:

1. Loopback IP
2. sysName
3. Public IP
4. Private IP
5. SNMP Agent IP

What Exactly Gets Discovered?

The discovery that you have just created adds a new discovery rule into the Network Management view of the Administration tab. You know that this discovery rule runs and discovers your device, but what exactly gets discovered on these devices? Well, the answer is that it depends on the manufacturer and model of the network device. On some devices, Operations Manager will discover the memory, DIMMs, processors, ports, temperature sensors, and power supplies. On other devices, it may only discover the interface. As we covered earlier on in this chapter, devices that are listed in the Excel spreadsheet published by Microsoft are certified for extended Operations Manager network monitoring. It’s these types of devices that provide the most detail.

Viewing a Certified Network Device

When you have discovered your network device, from the Operations Manager console browse to the Monitoring tab, expand the Network Monitoring folder, click the Network Devices view, and select your network device. Click the Diagram View link from the Tasks pane on the right side of the screen; this will show a view of the device and all of its components that have been discovered. Figure 8.10 shows a typical diagram view of a certified network device.

Figure 8.10 Network device diagram view

image
Different Methods, Same Results in Operations Manager
As you become familiar with the Operations Manager console, you will notice that sometimes there are a number of different methods available to carry out the same type of action or task that you are looking to use. An example of this is when you want to run the Discovery Wizard to discover network devices for monitoring. The Discovery Wizard can be initiated by right-clicking on any view on the Administration tab and selecting it from the context menu. You can just as easily select the Discovery Wizard link that is located at the foot of the administration view or, if you have the Administration Overview window open, you can select the Configure Computers And Devices To Manage action.

Managing Network Monitoring

Once a device has been discovered, you have a number of methods of viewing it and seeing how it’s performing. As with other objects in Operations Manager, you can take a basic diagram view and look at the device to get a much deeper view of all the child components beneath it. The diagram view is possibly the best place to start managing network monitoring for your device. From inside the diagram, it’s easy to put any of the device components into Maintenance Mode, navigate to different views, and run tasks and reports.

The diagram view gives you granular access to other views such as the alert and performance views and allows you the flexibility to alternate child component management as you wish directly from a central location.

To demonstrate this type of network device management, the following steps will guide you through the process of viewing specific interface performance counters from inside a diagram of the parent (top-level) network device.

1. From the monitoring view in the Operations Manager console, expand the Network Monitoring folder, click the Network Devices view, and then select a discovered network device from the central pane.
2. When you have selected the network device that you want to manage, as shown in Figure 8.11 click the Diagram View link from the Tasks pane on the right-hand side.

Figure 8.11 Opening a network device diagram view

image
3. Once the diagram view opens, click the top-level icon that represents your network device and then choose the Performance View link from the Tasks pane on the left-hand side. Figure 8.12 shows an example of this.

Figure 8.12 Opening a top-level performance view

image
4. When this performance view appears, as shown in Figure 8.13, you will see a collection of performance rules specific to the top-level device. These rules include all counters for memory, CPU, and interfaces on the device.

Figure 8.13 Network device performance rules

image
5. If instead of choosing a performance view from the top-level icon, however, you decide to expand the diagram right down to select an interface that is being monitored and then choose to open the performance view from here, you will now only see the performance counters specific to that interface and the Memory and CPU counters are not present. Figure 8.14 shows this granular performance view of your network interface.

Figure 8.14 Network interface performance view

image

Reporting on Your Network Devices

With the addition of network monitoring to Operations Manager, you’re probably wondering, “How can I report on the state of a network device?” Aside from the standard availability reports on the devices, you get three new reports to look at the interface and two new reports to look at the device.

Port-Based Reports

  • Interface Error Packet Analysis
  • Interface Packet Analysis
  • Interface Traffic Volume

Device-Based Reports

  • Memory Utilization
  • Processor Utilization

Let’s have a look at the third report in the list—Interface Traffic Volume. The following steps describe what you need to do to run this report against an interface on your network:

1. From the Operations Manager console, select the Reporting tab and then select the Network Management Reports folder to display the five reports that are specific to the Network Monitoring feature.
2. Double-click on the Interface Traffic Volume report to configure your parameters.
3. When the Report Parameter window opens, notice that there are no parameters specified. These will need to be supplied by you. As this is an Interface Traffic Volume report that you want to run, you need to select an interface to target the report at. Click the Add Object button, and then click the Search button to display a list of network device interfaces to choose from. Select the interface (or interfaces if you want to run the report against multiple instances), click the Add button, and then click OK to return to the report configuration window.
4. Once you have your interface targeted, choose the units that you want it to be measured in—for example bits, kilobits, megabits, or gigabits—and then define the date range for the report. Figure 8.15 shows the report parameter page populated with some interface-specific data.

Figure 8.15 Interface Report Parameter page

image
5. Once you have configured the parameters, click the Run button at the top left of the window to initiate the new report. This report displays results in easy-to-understand values, as you can see in Figure 8.16. As a side note, if you select the default of bits/sec, the report displays the results in a rendered hexadecimal value, so it is not so easy to make sense of the values.

Figure 8.16 Interface Traffic Volume report

image
Targeting Interface Reports
When you create a network interface report from scratch using the Reporting tab in the Operations Manager console, you will find that the target interface you want to report on needs to be selected from a filtered list before you can run the report. This can sometimes be cumbersome; if you know the exact interface that you need information on, there’s a much quicker way to run these types of reports.
All you need to do is to open any network device view that shows interfaces; for this example, we’ll use the Network Summary dashboard. Click the interface that you want to report on from the central window; then, from the Report Tasks menu on the left side of the screen, run whatever interface report that you wish. When the report opens, it will have automatically targeted itself against the selected interface from the original view.

Running Tasks

A key feature of Operations Manager is the customized tasks that come built in with each management pack. These tasks are specific to the alert or object that you are looking at within the different console views. Network Monitoring is no different, and there are a number of tasks that you can use when managing your network devices. The Network Monitoring tasks are as follows:

Ping The Ping (ping.exe) task performs a simple Internet Control Message Protocol (ICMP) command against the selected network device from the management server that is responsible for managing it. Figure 8.17 shows an output window from the Ping task that successfully confirms connectivity to a network device.

Figure 8.17 Ping task output

image
SNMP GET This task simply retrieves a value for the Object Identifier (OID) from the network device. In Figure 8.18, you can see the OID value returned for an F5 Big-IP network device.

Figure 8.18 SNMP GET output

image
SNMP Walk This task is an SNMP application that uses SNMP GETNEXT requests to retrieve an MIB subtree and output the results to the console. It specifies an OID of .1.3.6.1.2.1 as part of its Operations Manager Network Monitoring context. It is used to troubleshoot behavior and verify the configuration of SNMP devices. Figure 8.19 shows the task having run successfully and you can see that it is outputting its findings to a file on the local C: drive. Figure 8.20 shows the contents of this SNMP Walk output file.

Figure 8.19 SNMP Walk task

image

Figure 8.20 SNMP Walk output file

image
Telnet Console Launches the Telnet console (telnet.exe) and connects to the selected network device for troubleshooting purposes. This task is dependent on the computer that the task is being run from having the Telnet Client feature actually installed.
Traceroute This task (tracert.exe) is a diagnostic tool that traces the network route path (hops) and transit times. Figure 8.21 shows that, to reach your network device, you just needed to travel one hop on the network to find it.

Figure 8.21 Traceroute output dialog box

image

There are two additional network monitoring tasks that are worth knowing about, and to run these tasks, you need to select a network interface within one of the dashboard or alert views. If you change from the device top level and go directly to the port, you get a different selection of tasks than the previous list. Specifically, these tasks are:

Disable Port Monitoring This task does simply what its description says it will do. You can disable port monitoring easily within Operations Manager by clicking on this task once you have selected the required network interface.
Enable Port Monitoring This task is the opposite of the Disable Port Monitoring task. When you select an interface and then click this task, you enable that particular report for monitoring.

Using Network Monitoring Groups

Now that you are managing the network device in Operations Manager, it’s time to focus on one of the main points of interest for a lot of people: the interface that their server is connected to. It may come as a surprise to you to learn that the default monitoring status for an interface that is connected to a computer is not monitored! Only ports that connect to other network devices are monitored.

This is the best approach, especially when you consider core switches that can contain hundreds of interfaces and VLANs. Monitoring every interface by default would create an unnecessary number of false alerts. For ports that connect network devices together, they are automatically added into a special group that is configured for interface monitoring. Figure 8.22 shows the groups that Operations Manager uses to deal with interface monitoring. If you want to access these groups, browse to the Authoring tab from within the Operations Manager console and select the Groups view.

Figure 8.22 Network monitoring groups

image
Managed Computer Network Adapters Group So you are the SQL Server administrator, you have a SQL Server instance running on a physical server, the Operations Manager agent is deployed, the network card is fully discovered as part of the Windows Server core OS MP, and by default this interface will appear in the Managed Computer Network Adapters group. You have to do nothing to get it there; it’s just the default behavior.
Relay Network Adapters Group When you run a full discovery and add a device that is connected to another device, the connecting interface for the two devices gets monitored automatically. Once again, this is default behavior and requires no additional administrative effort from you.
Critical Network Adapters Group If you add an interface to this group, it gets monitored. If for some reason your critical server interfaces were not being monitored as part of the Managed Computer Network Adapters group, adding them to this group will do the trick. In Figure 8.23 you can see the members of the group from an interface perspective. Notice that the Types column description indicates that each object type is a network interface.

Figure 8.23 Critical interface group members

image
Advanced Network Adapters Group This group contains interfaces and ports that require an advanced level of monitoring. The elevated monitoring that is assigned to this group involves running advanced performance counters like Cisco Collision packets, which are already reported as part error packets in the monitoring by the other three groups. If these types of performance counters and metrics are of interest to you, adding the interface to this group is a way to get that extra data.

Server Interface Discovery (Interface Stitching)

When an interface is discovered on a network device—particularly on a switch—Operations Manager will try to ascertain whether there is a server connected to that interface. If a server is connected on that interface, a connection between the two will be made. For this to happen, you obviously have to have discovered both the server and the network device, and for that to be possible, you need to have management packs such as the Windows Server Core OS deployed. If you wanted to show the relationship between the switch and clients like Windows 7, you would also have to have the Windows Client management pack imported and configured. This functionality is known as interface stitching.

The management packs required for interface stitching to take place are:

  • Microsoft.Windows.Server.NetworkDiscovery
  • Microsoft.Windows.Client.NetworkDiscovery
  • Windows Server 2003 Operating System
  • Windows Server 2008 Operating System
  • Windows 7 Client Operating Systems
  • Windows Vista Client Operating Systems

Of course, if you only want to discover servers, you don’t need any of the client management packs. The two Network Discovery management packs are installed by default when you first deploy Operations Manager.

When a server has been stitched to an interface on a network device the server will be displayed on the Network Vicinity dashboard once you select the Show Computers check box. As shown in Figure 8.24, when you highlight the green link between the device and the server and right-click to display the Health Explorer, the Health Explorer’s Availability view will tell you what network interface your server is connected to. In Figure 8.25, you can see the specific port being displayed in the Health Explorer.

Figure 8.24 Network segment link

image

Figure 8.25 Interface stitching

image

As you learned earlier in this chapter, when a device is being discovered a number of phases run, each going deeper into the device to see what can be discovered. On the third phase, the postprocessing phase, Operations Manager tries to associate the interfaces on a device with the network cards on servers. In the Operations Manager folder in the monitoring pane, the discovery will log two events in connection with the server discovery.

The connection itself is an aggregate of the two endpoints; therefore, you may still see the server unavailable if the switch goes down. There is no root cause correlation as such. This means that if you have a number of servers connected to the switch and the switch goes down, you are still going to be alerted by the many management packs you have loaded on the servers. You will, however, have the opportunity to do some fast route cost analysis via the network state views.

Interface Stitching with New Servers
When you install the Operations Manager agent onto a new server that is connected to an already discovered switch, after the new server discovery has run you will need to rerun the discovery of the switch to ensure that the interface stitching process ties the two discoveries together. This process is automatic if you have configured a scheduled network discovery and will occur on the next configured discovery schedule. If you have not configured a scheduled discovery and instead choose to run it on demand, you will need to manually rerun the switch discovery for interface stitching to complete.
A quick way to do this is as follows:
1. Select the Administration tab in the Operations Manager console.
2. Under Administration, expand Network Management and then click Discovery Rules.
3. Right-click on your discovery rule in the center of the screen and choose the Run option from the context menu.
The network device discovery rule that you had previously configured will now run and rediscover all the devices that have been specified. Once the discovery finishes, your newly installed server will be configured with interface stitching to the switch.

Network Monitoring Dashboards

One of the great out-of-the-box advances in network monitoring is the addition of four new dashboards. Table 8.1 shows the types of dashboards and their descriptions.

Table 8.1: Network Monitoring dashboards

Dashboard name Dashboard description
Network Summary Shows the overall health of the network with slowest response, highest CPU, and highest utilization views
Network Node Shows the health of a specific device on the network
Network Interface Displays statistics on individual network interfaces
Network Vicinity Shows a device and all of its interconnected neighbors; has an option to scale out to view Windows computers that are connected to a particular network device

Let’s start with the Network Summary dashboard. As Figure 8.26 shows, the Network Summary is a seven-pane dashboard that includes all your interfaces by default. You navigate to this dashboard from the Network Monitoring folder in the Monitoring area. This dashboard will be of most interest to the network admins because it’s focused on the performance and throughput of the device. It includes views on the slowest response times, highest CPU, interface utilization, send/receive errors, and so forth.

Figure 8.26 Network Summary dashboard

image

On the Network Summary dashboard, if you select a node you can then navigate to the Network Node or Network Vicinity dashboard. From any interface you can navigate to the Network Interface dashboard and three specific interface reports, including Interface Traffic Volume.

The Network Node dashboard includes a vicinity view along with availability, response times, processor usage, and details about your instance. As you can track the availability of the device over the last 30 days, it’s a great place to look if one of your applications has had reduced availability over the last month.

In Figure 8.27, the Network Vicinity dashboard contains the same view from the Network Node dashboard but larger. This dashboard view is great when you are looking at large and complex network environments including the servers attached.

Figure 8.27 Network Vicinity view

image

Figure 8.28 shows the Network Interface view, and you can see the Interface Dashboard focuses on a specific interface and drills into details like the number of bits sent and received, packets sent and received, and utilization. Also from this dashboard it is possible to access interface-specific reports.

Figure 8.28 Network Interface view

image

Network Vicinity Dashboard Limitations

The Network Vicinity dashboard is one of the best dashboards to come out of this new release of Operations Manager, but there are a few limitations that you need to be aware of. Some of these will be addressed in a later service pack or cumulative update release.

NIC Teaming If you have NIC teaming configured for any network adapters on your servers, these adapters will not be identified as “teamed” in the Network Vicinity dashboard. The connection state will be identified as it should be, but the dashboard will view it as a single connection.
Virtual Machine and Host Relationships With this version of Operations Manager, the Network Vicinity dashboard does not show a networking connection relationship between virtual machines and their hosts. This is because the virtual machines are associated with the same network device that their host is physically connected to. This functionality is expected to change with the release of Windows Server 2012 and the extended virtual networking and switching capabilities it provides.
OSI Layer 1 Devices Devices that don’t have MAC addresses such as old network hubs exist in Layer 1 of the Open Systems Interconnection (OSI) model. These types of Layer 1 devices will not be connected to servers or computers in the Network Vicinity dashboard. If you have any of these OSI Layer 1 devices in your environment, you will only be able to see a basic connection between them and any OSI Layer 2 or Layer 3 network devices and nothing else.
Unix/Linux Devices If you have deployed agents to Unix- or Linux-based devices, these agents will not display connectivity to your network devices in the Network Vicinity dashboard when you select the Show Computers option.

Troubleshooting Network Monitoring

Discovering your network devices and their components in the first place forms the basis of the most common problems that you are likely to encounter when working with Operations Manager network monitoring. This section will discuss some options on how to troubleshoot these types of issues and will help you to get your network devices monitored by the Operations Manager management servers.

Network Device Discovery Problems

The Operations Manager TechNet forums frequently have questions from people requesting assistance when they are unable to discover and add a network device. Once you get the devices into Operations Manager, however, the battle is over, so here are some troubleshooting tips to assist with the network discovery process:

  • Are there any firewalls between your management pool and your devices? The firewalls have to allow SNMP (UDP) and ICMP bidirectional communication on both ports 161 and 162 for discovery to work. Try to run a ping command to the device and see if you get a reply back from it, if a ping doesn’t work; it’s possible that a firewall is blocking communication to it.
  • A network device may need to have its access control list (ACL) changed to allow the management servers to connect to it. This is a security feature that most enterprise vendors have written into the firmware on their network devices that basically controls the IP addresses on a network that can communicate over SNMP with it. Check with your network administrator or the device vendor for further information on modifying the ACLs on your device and ensure your Operations Manager servers are allowed, at a minimum, read-only SNMP access.
I can’t Telnet to SNMP Port 161, why?
If you want to test that SNMP is enabled, then don’t be fooled into thinking that you can run a telnet command to port 161 to check if it’s turned on.
Generally, if you wanted to check if a particular TCP port was open, then you would use a simple telnet command to connect up to the port similar to: telnet NetworkDeviceIP PortNumber
You will find however, that if you try to apply this command to SNMP port 161, it will always fail to connect. The reason for this is that SNMP port 161 is not a TCP port but instead is a UDP port and as such, running a telnet command against it won’t work.
A good free utility that you can use to test SNMP connectivity is the Paessler SNMP Tester and you can download a copy of it from here:
http://www.paessler.com/tools/snmptester
  • Many network device discovery problems are related to a simple typing error when entering the SNMP community string to enable monitoring of the device. A good tip is always to write out the community string in Notepad or your word processor and copy it straight from there into the RunAs account that you are using for the discovery. That way, you can be sure that you are entering the correct community string every time.
  • Sometimes device discovery will fail if you have specified an incorrect SNMP version when carrying out the initial discovery. As you learned earlier, Operations Manager supports three versions of SNMP—v1, v2, and v3. If you are unsure of the SNMP version that your device supports, try the same rule with different versions until you communicate with the one that works.
  • Use the Operations Manager event logs to get more information on the problem. When a discovery rule has been configured, it’s possible to track the events that are created in Operations Manager through the Windows Event Viewer so as to track what is happening during the network discovery process. There are two events of interest when troubleshooting discovery problems: Event IDs 12002 and 12008. They are both information-based events. In Figure 8.29 you can see these types of events being raised, some event data on the logging computer, and also the discovery rule that has been used to discover the event.

    Figure 8.29 Network discovery events

    image
    Two other events of interest are Event IDs 12023 and 12024. The first 12023 event signals that the discovery has entered the device discovery phase. The 12024 event signifies that the device discovery process has finished. When the discovery has finished, the description of the event will tell you how many connections to computers it has made. In Figure 8.30 you can see that Operations Manager has processed and connected three computers to the network device.

    Figure 8.30 Port stitching events

    image
  • Each management server or gateway server can run only one discovery rule. If you try to create a new rule and do not have additional management servers to run this rule against, you will see a message stating “No management servers are available.” This restriction is shown in Figure 8.31.

Figure 8.31 Network discovery rule issue

image

Device Components Not Discovered

Consider this: You configure and run your discovery rule, and all is going well. Your device should get discovered relatively quickly and be ready to view and manage from within the Operations Manager console. When you go to the console to manage your device, you open a diagram view of the device expecting to see a number of components such as Processor, Memory, Interfaces, and so on, but find that it has only discovered a single interface and nothing else!

The reason for this is quite simple and is related to the fact that the particular device is not certified for use in Operations Manager and isn’t listed on the Excel spreadsheet discussed earlier in this chapter. As a result and due to no extended monitoring functionality, you will only be able to discover a minimum configuration for the device using SNMP.

Bottom Line

Explore network monitoring. Operations Manager can discover and monitor network devices that use three different versions of the Simple Network Management Protocol (SNMP): v1, v2c, and v3.
Master It You know that Operations Manager supports three versions of SNMP, but what other two protocols are supported?
Discover network devices. Resource pools provide logical grouping of management servers that enable you to distribute network monitoring between them. When you have your resource pools configured, there are a number of ways to perform discovery of your network devices.
Master It Operations Manager has two methods of network device discovery. What are these methods called and what’s the difference between them?
Manage network monitoring. With the Network Monitoring feature in Operations Manager, you have access to five new network specific reports. These five reports cover both interface port and device-based reporting.
Master It With device-based reporting, you have access to memory and processor utilization reports. Select the other three reports from this list that are focused on interface port reporting (choose 3):
a. Interface SNMP Discovery
b. Interface Error Packet Analysis
c. Interface Traffic Volume
d. Interface Link State
e. Interface Packet Analysis
Use network monitoring dashboards. Once you have discovered your network devices within Operations Manager, you need to be able to see the data collected from them in an easy-to-digest format. For this purpose, you have access to a number of dashboards that can provide in-depth transparency of your network environment.
Master It There are four network monitoring dashboards that you can use in your environment. The Network Summary, Network Node, and Network Interface dashboards are three of them. Name the fourth one, which provides a view of a device and all of its connected neighbors.
Troubleshooting network monitoring issues. One of the most common problems when dealing with Network Monitoring in Operations Manager is trying to get the discovery of your network devices working in the first place. Another common issue is that when your device does get discovered, you may not have all of the components of that device that you thought would be monitored actually show up.
Master It If you have discovered your device successfully with Operations Manager but, on inspection, you can’t find all of the components of that device such as CPU, fans, chassis, and memory and instead are presented with just a single network interface connection, what might be the problem and what can you do to resolve it?
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.137.157.45