Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Simple Network Management Protocol (SNMP) and NetFlow are two technologies available
on some Cisco IOS platforms that can automate the collection statistics. These statistics
can be used, for example, to establish a baseline in a troubleshooting scenario.
Table 3-3 contrasts these two technologies.
Although both SNMP and NetFlow are useful for statistical data collection, they target
different fundamental functions. For example, SNMP is primarily focused on device statistics,
whereas NetFlow is primarily focused on traffic statistics.
Chapter 3: The Maintenance and Troubleshooting Toolbox 67
Managed Device
Running an SNMP
Agent
NMS
SW1 R1
Figure 3-4 SNMP Sample Topology
SNMP
A device being managed by SNMP runs a process called an SNMP agent. A Network
Management System (NMS) can then query the agent for information, using the SNMP
protocol. SNMP version 3 (that is, SNMPv3) supports encryption and authentication of
SNMP messages; however, the most popular SNMP version deployed today is SNMPv2c.
SNMPv2c uses community strings for security. Specifically, for an NMS to be allowed to
read data from a device running an SNMP agent, the NMS must be configured with a
community string that matches the managed device’s read-only community string. For the
NMS to change the information on the managed device, the NMS must be configured
with a community string that matches the managed device’s read-write community string.
To enhance the security available with SNMPv2c, you can create an access list that determines
valid IP addresses or network addresses for NMS servers.
Figure 3-4 shows a topology using SNMP. In the topology, router R1 is running an SNMP
agent that the NMS server can query.
Example 3-20 illustrates the SNMP configuration on router R1. The snmp-server community
string [ro | rw] commands specify a read-only (that is, ro) community string of
CISCO and a read-write (that is, rw) community string of PRESS. Contact and location
information for the device is also specified. Finally, notice the snmp-server ifindex persist
command. This command ensures that the SNMP interface index stays consistent during
data collection, even if the device is rebooted. This consistency is important when data
is being collected for baselining purposes.
Example 3-20 SNMP Sample Configuration
R1# conf term
R1(config)# snmp-server community CISCO ro
R1(config)# snmp-server community PRESS rw
R1(config)# snmp-server contact demo@ciscopress.local
R1(config)# snmp-server location 3rd Floor of Wallace Building
R1(config)# snmp-server ifindex persist
NetFlow
Unlike SNMP, NetFlow can distinguish between different traffic flows. A flow is a series
of packets, all of which have shared header information such as source and destination IP
addresses, protocols numbers, port numbers, and Type of Service (TOS) field information.
NetFlow can keep track of the number of packets and bytes observed in each flow. This
192.168.0.228
Cisco Unified Communications
Manager Server
Web Server
NetFlow
Enabled
Router
10.8.8.6
IP Phone
192.168.1.50
NetFlow
Collector
SW1 R4 SW2
Fa 0/1 Fa 0/0
Figure 3-5 NetFlow Sample Topology
information is stored in a flow cache. Flow information is removed from a flow cache if
the flow is terminated, times out, or fills to capacity.
You can use the NetFlow feature as a standalone feature on an individual router. Such a
standalone configuration might prove useful for troubleshooting because you can observe
flows being created as packets enter a router. However, rather than using just a standalone
implementation of NetFlow, entries in a router’s flow cache can be exported to a NetFlow
collector prior to the entries expiring. After the NetFlow collector has received flow information
over a period of time, analysis software running on the NetFlow collector can produce
reports detailing traffic statistics.
Figure 3-5 shows a sample topology in which NetFlow is enabled on router R4, and a Net-
Flow collector is configured on a PC at IP address 192.168.1.50.
Example 3-21 illustrates the NetFlow configuration on router R4. Notice that the ip flow
ingress command is issued for both the Fast Ethernet 0/0 and Fast Ethernet 0/1 interfaces.
This ensures that all flows passing through the router, regardless of direction, can be monitored.
Although not required, router R4 is configured to report its NetFlow information
to a NetFlow collector at IP address 192.168.1.50. The ip flow-export source lo 0/0 command
indicates that all communication between router R4 and the NetFlow collector will
be via interface Loopback 0. A NetFlow version of 5 was specified. Note that although
version 5 is the most widely deployed, you should check the documentation for your
NetFlow collector software to confirm which version to configure. Finally, the ip flowexport
destination 192.168.1.50 5000 command is issued to specify that the NetFlow
collector’s IP address is 192.168.1.50, and communication to the NetFlow collector
should be done over UDP port 5000. Because NetFlow does not have a standardized
port number, please check your NetFlow collector’s documentation when selecting a port.
Example 3-21 NetFlow Sample Configuration
R4# conf term
R4(config)# int fa 0/0
R4(config-if)# ip flow ingress
R4(config-if)# exit
R4(config)# int fa 0/1
R4(config-if)# ip flow ingress
R4(config-if)# exit
R4(config)# ip flow-export source lo 0
R4(config)# ip flow-export version 5
R4(config)# ip flow-export destination 192.168.1.50 5000
R4(conig)# end
Although an external NetFlow collector is valuable for longer-term flow analysis, you can
issue the show ip cache flow command at a router’s CLI prompt to produce a summary of
flow information, as shown in Example 3-22. A troubleshooter can look at the output displayed
in Example 3-22 and be able to confirm, for example, that traffic is flowing between
IP address 10.8.8.6 (a Cisco IP Phone) and 192.168.0.228 (a Cisco Unified
Communications Manager server).
Both syslog (discussed in Chapter 1, “Introduction to Network Maintenance”) and SNMP
(introduced in this section) are protocols that can report the occurrence of specific events
on a network device. Although these protocols by themselves lack a mechanism to alert a
network administrator (for example, via e-mail) when a network event is logged, thirdparty
software is available that can selectively alert appropriate personnel when specific
events are logged.
Earlier, this section discussed how a network device running an SNMP agent can be
queried for information from an NMS. However, a network device running an SNMP
agent can also initiate communication with an NMS. If an interface goes down, for example,
the SNMP agent on a managed network device can send a message containing information
about the interface state change to an NMS. Such notifications that a managed
device sends to an NMS are called traps. These traps require an NMS to be interpreted
because they are not in a readable format.
Key
Topic
R4# show ip cache flow
...OUTPUT OMITTED...
Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)
Example 3-22 Viewing NetFlow Information Key
---------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow
TCP-Telnet 12 0.0 50 40 0.1 15.7 14.2
TCP-WWW 12 0.0 40 785 0.1 7.1 6.2
TCP-other 536 0.1 1 55 0.2 0.3 10.5
UDP-TFTP 225 0.0 4 59 0.1 11.9 15.4
UDP-other 122 0.0 114 284 3.0 15.9 15.4
ICMP 41 0.0 13 91 0.1 49.9 15.6
IP-other 1 0.0 389 60 0.0 1797.1 3.4
Total: 949 0.2 18 255 3.8 9.4 12.5
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
Fa0/0 10.3.3.1 Null 224.0.0.10 58 0000 0000 62
Fa0/1 10.8.8.6 Fa0/0 192.168.0.228 06 C2DB 07D0 2
Fa0/0 192.168.0.228 Fa0/1 10.8.8.6 06 07D0 C2DB 1
Fa0/0 192.168.1.50 Fa0/1 10.8.8.6 11 6002 6BD2 9166
Fa0/1 10.8.8.6 Fa0/0 192.168.1.50 11 6BD2 6002 9166
Fa0/0 10.1.1.2 Local 10.3.3.2 06 38F2 0017 438
Providing Notifications for Network Events
Whereas responding to problem reports from users is a reactive form of troubleshooting,
monitoring network devices for significant events and responding to those events
is a proactive form of troubleshooting. For example, before a user loses connectivity
with the Internet, a router that is dual-homed to the Internet might report the event
of one of its Internet connections going down. The redundant link can then be
repaired, in response to the notification, thus resolving the problem without users
being impacted.
Example 3-23 demonstrates how to enable a router to send SNMP traps to an NMS.
The snmp-server host 192.168.1.50 version 2c CISCOPRESS command points router
R4 to an SNMP server (that is, an NMS) at IP address 192.168.1.50. The SNMP server is
configured for SNMP version 2c and a community string of CISCOPRESS. The snmpserver
enable traps command attempts to enable all traps. Notice from the output,
however, that a couple of the traps are mutually exclusive, causing one of the traps to
not be enabled. You can view the enabled traps by using the show run | include traps
command. Rather than enabling all possible traps with the snmp-server enable traps
command, you can selectively enable traps using the snmp-server enable traps trapname
command.
R4# conf term
R4(config)# snmp-server host 192.168.1.150 version 2c CISCOPRESS
R4(config)# snmp-server enable traps
% Cannot enable both sham-link state-change interface traps.
% New sham link interface trap not enabled.
R4(config)# end
R4# show run | include traps
Key
Topic
Example 3-23 Enabling SNMP Traps
snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart
snmp-server enable traps vrrp
snmp-server enable traps ds1
snmp-server enable traps gatekeeper
snmp-server enable traps tty
snmp-server enable traps eigrp
snmp-server enable traps xgcp
snmp-server enable traps ds3
...OUTPUT OMITTED...
The messages received via syslog and SNMP are predefined within Cisco IOS. This large
collection of predefined messages accommodates most any network management requirement;
however, Cisco IOS supports a featured called EEM that allows you to create your
own event definitions and specify custom responses to those events. An event can be defined
based on syslog messages, SNMP traps, and entering specific Cisco IOS commands,
as just a few examples. In response to a defined event, EEM can perform various actions,
including sending an SNMP trap to an NMS, writing a log message to a syslog server,
executing specified Cisco IOS commands, sending an e-mail to an appropriate party, or
executing a tool command language (Tcl) script.
To illustrate the basic configuration steps involved in configuring EEM, consider Example
3-24. The purpose of the configuration is to create a syslog message, which will be displayed
on the router console, when someone clears the router’s interface counters using
the clear counters command. The message should remind the administrator to update the
network documentation, listing the rationale for clearing the interface counters.
Example 3-24 EEM Sample Configuration
R4# conf term
R4(config)# event manager applet COUNTER-RESET
R4(config-applet)# event cli pattern “clear counters” sync no skip no occurs 1
R4(config-applet)# action A syslog priority informational msg “Please update
network documentation to record why the counters were reset.”
R4(config-applet)# end
Key
Topic
The event manager applet COUNTER-RESET command creates an EEM applet named
COUNTER-RESET and enters applet configuration mode. The event command specifies
what you are looking for in your custom-defined event. In this example, you are looking
for the CLI command clear counters. Note that the clear counters command would be
detected even if a shortcut (for example, cle co) were used. The sync no parameter says
that the EEM policy will run asynchronously with the CLI command. Specifically, the
EEM policy will not be executed before the CLI command executes. The skip no parameter
says that the CLI command will not be skipped (that is, the CLI command will be executed).
Finally, the occurs 1 parameter indicates that the EEM event is triggered by a
single occurrence of the clear counters command being issued.
The action command is then entered to indicate what should be done in response to the
defined event. In Example 3-24, the action is given a locally significant name of A and is
assigned a syslog priority level of informational. The specific action to be taken is producing
an informational message saying, “Please update network documentation to
record why the counters were reset.”
To verify the operation of the EEM configuration presented in Example 3-24, the clear
counters command is executed in Example 3-25. Notice that entering the clear counters
command triggers the custom-defined event, resulting in generation of a syslog message
reminding an administrator to document the reason he cleared the interface counters.
Example 3-25 Testing EEM Configuration
R4# clear counters
Clear “show interface” counters on all interfaces [confirm]
R4#
*Mar 3 08:41:00.582: %HA_EM-6-LOG: COUNTER-RESET: Please update network documentation
to record why the counters were reset.
No comments:
Post a Comment