IOS Maintenance and Monitoring Tools – Part 4

Simple Network Management Protocol

The Simple Network Management Protocol, SNMP, is a widely used management protocol and defined set of standards for communications with devices connected to an IP network. SNMP provide a means to monitor and control network devices. Like Cisco IOS IP SLA operations, SNMP can be used to collect statistics, monitor device performance and provide a baseline of the network and is one of the most commonly used network maintenance and monitoring tools.

SNMP is an Application Layer (Layer 7) protocol that facilitates the exchange of management information between network devices using UDP ports 161 and 162. An SNMP-managed network consists of a management system, agents, and managed devices. The management system executes monitoring applications and controls managed devices. The management systems execute most of the management processes and provide the bulk of memory resources used for network management. A network might be managed by one or more management systems. Examples of SNMP management systems include HP OpenView and SolarWinds.

An SNMP agent resides on each managed device and translates local management information data, such as performance information or event and error information caught in software traps, into a readable form for the management system. SNMP agents use get-requests that transport data to the network management software. SNMP agents capture data from Management Information Bases (MIBs), which are device parameter and network data repositories, or from error or change traps.

A managed element, such as a router, switch, computer, or firewall, is accessed via the SNMP agent. Managed devices collect and store management information, making it available through SNMP to other management systems having the same protocol compatibility. Figure 1-2 illustrates the interaction of the three primary components of an SNMP-managed network:

Fig. 1-2. SNMP Network Component Interaction

Referencing Figure 1-2 above, R1 is the SNMP-managed device. Logically residing on the device is the SNMP agent. The SNMP agent translates local management information data, stored in the management database of the managed device, into a readable form for the management system, which is also referred to as the Network Management System (NMS).

When using SNMP, managed devices are monitored and controlled using three common SNMP commands. These three commands are the read, write and trap commands. The read command is used by an NMS to monitor managed devices. This is performed by the NMS examining different variables that are maintained by managed devices. The write command is used by an NMS to control managed devices. Using this command, the NMS can change the values of variables stored within managed devices. Finally, the SNMP trap command is used by managed devices to report events to the NMS. Devices can be configured to send SNMP traps or informs to an NMS. The traps and informs that are sent are dependent on the version of Cisco IOS software running on the device, as well as the platform.

SNMP traps are simply messages that alert the SNMP manager of a condition on the network. An example of an SNMP trap could include an interface transitioning from an up state to a down state. The primary issue with SNMP traps is that they are unacknowledged. This means that the sending device is incapable of determining if the trap was received by the NMS.

SNMP informs are SNMP traps that include a confirmation of receipt from the SNMP manager. These messages can be used to indicate failed authentication attempts, or the loss of a connection to a neighbor router, for example. If the manager does not receive an inform request, it does not send a response. If the sender never receives a response, the inform request can be sent again. Thus, informs are more likely to reach their intended destination.

While informs are more reliable than traps, the downside is that they consume more resources on both the router and in the network. Unlike a trap, which is discarded as soon as it is sent, an inform request must be held in memory until a response is received or the request times out. Also, traps are sent only once, while an inform may be resent several times if a response is not received from the SNMP server (NMS).

Figure 1-3 illustrates the communication between the SNMP manager and the Simple Network Management Protocol agent for sending traps and informs:

Fig. 1-3. UDP Ports used by the NMS and Managed Element

There are three versions of SNMP, which are versions 1, 2, and 3. Version 1 or SNMPv1 is the initial implementation of the SNMP protocol. SNMPv1 operates over protocols such as User Datagram Protocol (UDP), Internet Protocol (IP), and the OSI Connectionless Network Service (CLNS). SNMPv1 is widely used and is the de facto network-management protocol that is used within the Internet community.

SNMPv2 revises SNMPv1 and includes improvements in the areas of performance, security, confidentiality, and manager-to-manager communications. SNMPv2 also defines two new operations: GetBulk and Inform. The GetBulk operation is used to efficiently retrieve large blocks of data. The Inform operation allows one NMS to send trap information to another NMS and to then receive a response. In SNMPv2, if the agent responding to GetBulk operations cannot provide values for all the variables in a list, it provides partial results.

SNMPv3 provides three additional security services that are not available in previous versions of SNMP. The additional security features provided in SNMPv3 are message integrity, authentication, and encryption. SNMPv3 uses message integrity to ensure that a packet has not been tampered with in-transit. SNMPv3 also uses authentication, which is used to determine if the message is from a valid source. And finally, SNMPv3 provides encryption, which is used to scramble the contents of a packet to prevent it from being seen by unauthorized sources.

NOTE: You are not required to go into detail on SNMP versions in the TSHOOT exam. Instead, emphasis should simply be placed on having a basic understanding of the protocol and how it is used as a monitoring and maintenance tool. Additional theoretical and configuration information on SNMP can be found in the current SWITCH guide or online at www.howtonetwork.org.

In Cisco IOS software, the snmp-server host [hostname | address] command is used to specify the hostname or IP address of the NMS that the local device will send traps or informs to. To allow the NMS to poll the local device, SNMPv1 and SNMPv2c require that a community string be specified for either read-only or read-write access using the snmp-server community <name> [ro | rw] global configuration command.

SNMPv3 does not use the same community-based form of security but is instead uses user and group security. The following configuration example illustrates how to configure the local device with two community strings, one for read-only access and the other for read-write access. In addition, the local device is also configured to send SNMP traps for Cisco IOS IP SLA operations and syslog to 1.1.1.1 using the read-only community string:

Figure 1-4 shows a sample report based for device resource utilization and availability based on SNMP polling using the ManageEngine OpManager network monitoring software:

Fig. 1-4. Sample SNMP Report on Device Resource Utilization

Cisco IOS NetFlow

Like and SNMP, Cisco IOS NetFlow is a powerful maintenance and monitoring tool that can be used to baseline network performance and as well assist in troubleshooting. However, there are some significant differences between Cisco IOS NetFlow and SNMP. The first difference is that while SNMP reports primarily on device statistics, e.g. resource utilization, etc, Cisco IOS NetFlow reports on traffic statistics, e.g. packets and bytes.

The second difference between these two tools is that SNMP is a poll-based protocol, meaning that the managed device is polled for information. Cisco IOS NetFlow, however, is a push-based technology, meaning that the device on which NetFlow is configured sends out information that it has collected locally to a central repository. For this reason, NetFlow and SNMP complement each other and should be used together as part of the standard network maintenance and monitoring toolkit. They are not replacements for each other. This is often a misunderstood concept. It is important to ensure that you remember this.

Another difference is that while SNMP can provide traffic statistics, SNMP cannot differentiate between individual flows. However, Cisco IOS NetFlow can. A flow is simply a series of packets with the same source and destination IP address, source and destination ports, protocol interface and class of service parameters. For IP applications, an IP flow is based on a set of five and up to seven IP packet attributes which may include the following:

1. Destination IP address
2. Source IP address
3. Source port
4. Destination port
5. Layer 3 protocol type
6. Class of Service
7. Router or switch interface

In addition to these IP attributes, other additional information is also included with a flow. This additional information includes timestamps, which are useful for calculating packets and bytes per second. Timestamps also provide information on the life (duration) of a flow. The flow also includes next-hop IP address information, including BGP routing Autonomous Systems information. Subnet mask information for the flow source and destination addresses is also included in addition to flags for TCP traffic, which can be used to examine the TCP handshakes.

This means that Cisco IOS NetFlow can be used for network traffic accounting, usage-based network billing, network planning, security, Denial of Service (DoS) monitoring capabilities, and network monitoring, in addition to providing information about network users and applications, peak usage times, and traffic routing making it a very powerful maintenance, monitoring and also troubleshooting tool.

Cisco IOS NetFlow gathers the flow information and stores it in a database called the NetFlow cache or simply the flow cache. Flow information is retained until the flow is terminated or stopped, times out or the cache is filled. There are two methods that can be used to access the data stored in the flow: using the CLI, i.e. using show commands, or exporting the data and then view it using some type of reporting tool. Figure 1-5 illustrates NetFlow operation on a Cisco IOS router and how the flow cache is populated:

Fig. 1-5. Basic NetFlow Operation and Flow Cache Population

Referencing Figure 1-5, ingress traffic received is the local router. This traffic is inspected by the router and IP attribute information is used to create a flow. The flow information is then stored in the flow cache. This information can be viewed using the CLI or can also be exported to an external destination, referred to as a NetFlow Collector, where the same information can then be viewed using an application reporting tool. The following steps are used to implement NetFlow data reporting to the NetFlow collector:

1. Cisco IOS NetFlow is configured on the device to capture flows to the NetFlow cache
2. NetFlow export is configured to send flows to the collector
3. The NetFlow cache is searched for flows that have been inactive for a certain period of time, have been terminated, or for active flows that last greater than the active timer
4. Those identified flows are exported to the NetFlow collector server
5. Approximately 30 to 50 flows are bundled together and typically transported via UDP
6. The NetFlow collector software creates real-time or historical reports from the data

There are three primary steps required when configuring Cisco IOS NetFlow. These steps are:

1. Configuring the interface to capture flows into the NetFlow cache using the ip flow ingressinterface configuration command on all interfaces for which you want information to be captured and stored in the flow cache. It is important to remember that NetFlow is configured on a per-interface basis only.

The NetFlow information is then stored on the local router and can be viewed using the show ip cache flow command on the local device.

In the event that you want to export data to the NetFlow Collector, two additional tasks will be required. These two additional tasks include the following:

1. Configuring the Cisco IOS NetFlow version or format to use via the ip flow-export version [1 | 5 | 9] global configuration command. NetFlow version 1 (v1) is the original format supported in the initial NetFlow releases. This version should be used only when it is the only NetFlow data export format version that is supported by the application that you are using to analyze the exported NetFlow data. Version 5 exports more fields than version 1 and is the most widely deployed version. Version 9 is the latest Cisco IOS NetFlow version and is the basis of a new IETF standard. Version 9 is a flexible export format version
2. Configure and specify the IP address of the NetFlow Collector and then specify the UDP port that the NetFlow Collector will use to receive the UDP export from the Cisco device using the ip flow-export destination [hostname | address] <port> [udp] global configuration command. The [udp] keyword is optional and does not need to specified when using this command because User Datagram Protocol (UDP) is the default transport protocol used when sending data to the NetFlow Collector.

The following example illustrates how to enable NetFlow for a specified router interface:

Following this configuration, the show ip cache flow command can be used to view collected statistics in the flow cache:

The following example illustrates how to configure and enable NetFlow data collection for the specified router interfaces and then export the data to a NetFlow Collector with the IP address 150.1.1.254 over UDP port 5000 using NetFlow version 5 or the version 5 data format:

Following this configuration, the collected information can then be viewed using an application reporting tool on the NetFlow Collector. Despite the export of the data, the show ip cache flowcommand can still be used to view statistics on the local device, which can be a useful tool when troubleshooting network issues or problem reports.