Section 40 Tasks
- Read today’s lesson notes (below)
- Review yesterday’s lesson notes
- Complete today’s lab
- Read the ICND2 cram guide
- Spend 15 minutes on the subnetting.org website
Logging messages and events both locally and to a syslog server is a core maintenance task.
Syslog is a protocol that allows a host to send event notification messages across IP networks to event message collectors – also known as syslog servers or syslog daemons. In other words, a host or a device can be configured in such a way that it generates a syslog message and forwards it to a specific syslog daemon (server).
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 provides a means to monitor and control network devices. Like Cisco IOS IP SLA operations (which allow customers to analyse IP service levels using active traffic monitoring for measuring network performance), 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.
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.
Today you will learn about the following:
- Syslog
- SNMP
- Netflow
This lesson maps to the following CCNA syllabus requirements:
- Configure and verify syslog
- Utilise syslog outputs
- Describe SNMP v2 and v3
- Utilise netflow data
Logging
A syslog daemon or server is an entity that listens to the syslog messages that are sent to it.
You cannot configure a syslog daemon to ask a specific device to send it syslog messages. In other words, if a specific device has no ability to generate syslog messages, then a syslog daemon cannot do anything about it. In the real world, corporations typically use SolarWinds (or similar) software for syslog capturing. Additionally, freeware such as the Kiwi Syslog daemon is also available for syslog capturing.
Syslog uses User Datagram Protocol (UDP) as the underlying transport mechanism, so the data packets are unsequenced and unacknowledged. While UDP does not have the overhead included in TCP, this means that on a heavily used network, some packets may be dropped and therefore logging information will be lost. However, Cisco IOS software allows administrators to configure multiple syslog servers for redundancy. A syslog solution is comprised of two main elements: a syslog server and a syslog client.
The syslog client sends syslog messages to the syslog sever using UDP as the Transport Layer protocol, specifying a destination port of 514. These messages cannot exceed 1024 bytes in size; however, there is no minimum length. All syslog messages contain three distinct parts: the priority, the header, and the message.
The priority of a syslog message represents both the facility and the severity of the message. This number is an 8-bit number. The first 3 least significant bits represent the severity of the message (with 3 bits, you can represent 8 different severities) and the other 5 bits represent the facility. You can use these values to apply filters on the events in the syslog daemon.
NOTE: Keep in mind that these values are generated by the applications on which the event is generated, not by the syslog server itself.
The values set by Cisco IOS devices are listed and described below in Table 40.1 (please memorise the levels and level names):
Table 40.1 – Cisco IOS Software Syslog Priority Levels and Definitions
In syslog, the facility is used to represent the source that generated the message. This source can be a process on the local device, an application, or even an operating system. Facilities are represented by numbers (integers). In Cisco IOS software, there are eight local use facilities that can be used by processes and applications (as well as the device itself) for sending syslog messages. By default, Cisco IOS devices use facility local7 to send syslog messages. However, it should be noted that most Cisco devices provide options to change the default facility level. In Cisco IOS software, the logging facility [facility] global configuration command can be used to specify the syslog facility. The options available with this command are as follows:
R1(config)#logging facility ? auth Authorization system cron Cron/at facility daemon System daemons kern Kernel local0 Local use local1 Local use local2 Local use local3 Local use local4 Local use local5 Local use local6 Local use local7 Local use lpr Line printer system mail Mail system news USENET news sys10 System use sys11 System use sys12 System use sys13 System use sys14 System use sys9 System use syslog Syslog itself user User process uucp Unix-to-Unix copy system
To send messages via syslog, you must perform the following sequence of steps on the device:
- Globally enable logging on the router or switch using the logging on configuration command. By default, in Cisco IOS software, logging is enabled; however, it is only enabled to send messages to the console. The logging on command is a mandatory requirement when sending messages to any destination other than the console.
- Specify the severity of messages to send to the syslog server using the logging trap [severity] global configuration command. You can specify the severity numerically or using the equivalent severity name.
- Specify one or more syslog server destinations using the logging [address] or logging host [address] global configuration commands.
- Optionally, specify the source IP address used in syslog messages using the logging source-interface [name]. This is a common practice on devices with multiple interfaces configured. If this command is not specified, then the syslog message will contain the IP address of the router or switch interface used to reach the server. If there are multiple interfaces for redundancy, this address may change when the primary path (interface) is down. Therefore, it is typically set to a Loopback interface.
The following configuration example illustrates how to send all informational (level 6) and below messages to a syslog server with the IP address 192.168.1.254:
R2(config)#logging on R2(config)#logging trap informational R2(config)#logging 192.168.1.254
This configuration can be validated using the show logging command, as illustrated below:
R2#show logging
Syslog logging: enabled (11 messages dropped, 1 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)
Console logging: disabled
Monitor logging: level debugging, 0 messages logged, xml disabled,filtering disabled
Buffer logging: disabled, xml disabled, filtering disabled
Logging Exception size (4096 bytes)
Count and timestamp logging messages: disabled
No active filter modules.
Trap logging: level informational, 33 message lines logged
Logging to 192.168.1.254(global) (udp port 514, audit disabled, link up), 2 message lines logged, xml disabled,
filtering disabled
When configuring logging in general, it is important to ensure that the router or switch clocks reflect the actual current time, which allows you to correlate the fault data. Inaccurate or incorrect timestamps on log messages make the fault and problem isolation using a filtration and correlation process very difficult and very time consuming. In Cisco IOS devices, the system clock can be configured manually or the device can be configured to synchronise its clock with a Network Time Protocol (NTP) server. These two options are discussed in the following sections.
Manual clock or time configuration is fine if you have only a few internetwork devices in your network. In Cisco IOS software, the system time is configured using the clock set hh:mm:ss [day & month | month & day] [year] privileged EXEC command. It is not configured or specified in Global Configuration mode. The following configuration example illustrates how to set the system clock to October 20 12:15 AM:
R2#clock set 12:15:00 20 october 2010
Alternatively, the same configuration could be implemented on the router as follows:
R2#clock set 12:15:00 october 20 2010
Following this configuration, the show clock command can be used to view the system time:
R2#show clock 12:15:19.419 UTC Wed Oct 20 2010
One interesting observation of note is that when the system time is configured manually or set using the clock set command, it defaults to the GMT (UTC) time zone, as can be seen above. In order to ensure that the system clock reflects the correct time zone, for those who are not in the GMT time zone, you must use the clock timezone [time zone name] [GMT offset] global configuration command. For example, the United States has six different time zones, each with a different GMT offset. These time zones are Eastern Time, Central Time, Mountain Time, Pacific Time, Hawaii Time, and Alaska Time.
In addition, some of the time zones use Standard Time and Daylight Saving Time. Given this, it is important to ensure that the system time is set correctly (Standard or Daylight Saving) on all devices when manually configuring the system clock. The following configuration example illustrates how to set the system clock to 12:40 AM on October 20 for the Central Standard Time (CST) time zone, which is six hours behind GMT:
R2#config t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#clock timezone CST -6 R2(config)#end R2#clock set 12:40:00 october 20 2010
Following this configuration, the system clock on the local router now shows the following:
R2#show clock 12:40:17.921 CST Wed Oct 20 2010
NOTE: If you use the clock set command before the clock timezone command, then the time that you specified using the clock set command will be offset by using the clock timezone command. For example, assume that the configuration commands that are used in the example above were entered on the router as follows:
R2#clock set 12:40:00 october 20 2010 R2#config t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#clock timezone CST -6 R2(config)#end
Because the clock set command is used first, the output of the show clock command on the router would show the system clock offset by 6 hours, as specified using the clock timezone command. This behaviour is illustrated in the following output on the same router:
R2#show clock 06:40:52.181 CST Wed Oct 20 2010
NOTE: Cisco IOS routers and switches can be configured to switch automatically to summertime (Daylight Saving Time) using the clock summer-time zone recurring [week day month hh:mm week day month hh:mm [offset]] global configuration command. This negates the need to have to adjust the system clock manually on all manually configured devices during Standard Time and Daylight Saving Time periods.
The second method of setting or synchronising the system clock is to use a Network Time Protocol (NTP) server as a reference time source. This is the preferred method in larger networks with more than just a few internetwork devices. NTP is a protocol that is designed to time-synchronise a network of machines. NTP is documented in RFC 1305 and runs over UDP.
An NTP network usually gets its time from an authoritative time source, such as a radio clock or an atomic clock attached to a time server. NTP then distributes this time across the network. NTP is extremely efficient; no more than one packet per minute is necessary to synchronise two machines to within a millisecond of one another.
NTP uses the concept of a stratum to describe how many NTP hops away a machine is from an authoritative time source. Keep in mind that this is not routing or switching hops, but NTP hops, which is a totally different concept. A stratum 1 time server typically has a radio or atomic clock directly attached, while a stratum 2 time server receives its time via NTP from a stratum 1 time server, and so on. When a device is configured with multiple NTP reference servers, it will automatically choose as its time source the machine with the lowest stratum number that it is configured to communicate with via NTP.
In Cisco IOS software, a device is configured with the IP addresses of one or more NTP servers using the ntp server [address] global configuration command. As previously stated, multiple NTP reference addresses can be specified by repeatedly using the same command. In addition, this command can also be used to configure security and other features between the server and the client. The following configuration example illustrates how to configure a device to synchronise its time with an NTP server with the IP address 10.0.0.1:
R2(config)#ntp server 10.0.0.1
Following this configuration, the show ntp associations command can be used to verify the communications between the NTP devices, as illustrated in the following output:
R2#show ntp associations address ref clock st when poll reach delay offset disp *~10.0.0.1 127.127.7.1 5 44 64 377 3.2 2.39 1.2 * master (synced), # master (unsynced), + selected, - candidate, ~ configured
The address field indicates the IP address of the NTP server as confirmed by the value 10.0.0.1 specified under this field. The ref clock field indicates the reference clock used by that NTP server. In this case, the IP address 127.127.7.1 indicates that the device is using an internal clock (127.0.0.0/8 subnet) as its reference time source. If this field contained another value, such as 192.168.1.254, for example, then that would be the IP address the server was using as its time reference.
Next, the st field indicates the stratum of the reference. From the output printed above, you can see that the 10.0.0.1 NTP device has a stratum of 5. The stratum on the local device will be incremented by 1 to a value of 6, as shown below, because it receives its time source from a server with a stratum value of 5. If another device was synchronised to the local router, it would reflect a stratum of 7 and so forth. The second command that is used to validate the NTP configuration is the show ntp status command, the output of which is illustrated below:
R2#show ntp status Clock is synchronized, stratum 6, reference is 10.0.0.1 nominal freq is 249.5901 Hz, actual freq is 249.5900 Hz, precision is 2**18 reference time is C02C38D2.950DA968 (05:53:22.582 UTC Sun Mar 3 2002) clock offset is 4.6267 msec, root delay is 3.16 msec root dispersion is 4.88 msec, peer dispersion is 0.23 msec
The output of the show ntp status command indicates that the clock is synchronised to the configured NTP server (10.0.0.1). This server has a stratum of 5, hence the local device reflects a stratum of 6. An interesting observation when NTP is configured is that the local time still defaults to GMT, as can be seen in the bolded section above. To ensure that the device displays the correct time zone, you must issue the clock time-zone command on the device.
After the system clock has been set, either manually or via NTP, it is important to ensure that the logs sent to the server contain the correct timestamps. This is performed using the service timestamps log [datetime | uptime] global configuration command. The [datetime] keyword supports the following self-explanatory additional subkeywords:
R2(config)#service timestamps log datetime ? localtime Use local time zone for timestamps msec Include milliseconds in timestamp show-timezone Add time zone information to timestamp year Include year in timestamp <cr>
The [uptime] keyword has no additional subkeywords and configures the local router to include only the system uptime as the timestamp for sent messages. The following configuration example illustrates how to configure the local router to include the local time, millisecond information, and the time zone for all messages:
R2#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R2(config)#logging on R2(config)#logging console informational R2(config)#logging host 150.1.1.254 R2(config)#logging trap informational R2(config)#service timestamps log datetime localtime msec show-timezone
Following this configuration, the local router console would print the following message:
Oct 20 02:14:10.519 CST: %SYS-5-CONFIG_I: Configured from console by console Oct 20 02:14:11.521 CST: %SYS-6-LOGGINGHOST_STARTSTOP: Logging to host 150.1.1.254 started - CLI initiated
In addition, the syslog daemon on server 150.1.1.254 would also reflect the same, as illustrated in the Kiwi Syslog Manager screenshot in Figure 40.1 below:
Figure 40.1 – Configuring Log Timestamps
Simple Network Management Protocol
SNMP is an Application Layer (Layer 7) protocol, using UDP ports 161 and 162, that facilitates the exchange of management information between network devices. An SNMP-managed network consists of a management system, agents, and managed devices. The management system executes monitoring applications and controls managed devices. It also executes most of the management processes and provides the bulk of memory resources used for network management. A network might be managed by one or more management systems.
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, a switch, a computer, or a 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 40.2 below illustrates the interaction of the three primary components of an SNMP-managed network:
Figure 40.2 – SNMP Network Component Interaction
Referencing Figure 40.2, 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 Station (NMS).
When using SNMP, managed devices are monitored and controlled using three common SNMP commands: read, write, and trap. 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 whether 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 neighbour router, for example. If the manager does not receive an inform request, then it does not send a response. If the sender never receives a response, then 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. In addition, 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 40.3 below illustrates the communication between the SNMP manager and the SNMP agent for sending traps and informs:
Figure 40.3 – UDP Ports Used by the NMS and the SNMP-Managed Element
The three versions of SNMP 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 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 retrieve large blocks of data efficiently. The Inform operation allows one NMS to send trap information to another NMS and then to receive a response. In SNMPv2, if the agent responding to GetBulk operations cannot provide values for all the variables in a list, then it provides partial results.
SNMPv3 provides the following three additional security services that are not available in previous versions of SNMP: message integrity, authentication, and encryption. SNMPv3 uses message integrity to ensure that a packet has not been tampered with in-transit. SNMPv3 also utilises authentication, which is used to determine whether the message is from a valid source. Finally, SNMPv3 provides encryption, which is used to scramble the contents of a packet to prevent it from being seen by unauthorised sources.
In Cisco IOS software, the snmp-server host [hostname | address] command is used to specify the hostname or IP address of the NMS to which the local device will send traps or informs. 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 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:
R2#config t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#snmp-server community unsafe RO R2(config)#snmp-server community safe RW R2(config)#snmp-server host 1.1.1.1 traps readonlypassword rtr syslog
Figure 40.4 below illustrates a sample report for device resource utilisation and availability based on SNMP polling using ManageEngine OpManager network monitoring software:
Figure 40.4 – Sample SNMP Report on Device Resource Utilisation
Cisco IOS NetFlow
Like SNMP, Cisco IOS NetFlow is a powerful maintenance and monitoring tool that can be used to baseline network performance and 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 utilisation, 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. It can also be considered push-based in the instance that a SNMP device sends a trap (event report) to a management station. 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. However, they are not replacements for each other; this is often a misunderstood concept and it is important that you remember this.
An IP flow is based on a set of five, and up to seven, IP packet attributes, which may include the following:
- Destination IP address
- Source IP address
- Source port
- Destination port
- Layer 3 protocol type
- Class of Service
- 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.
In short, 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. All of this makes it a very powerful maintenance, monitoring, and 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. Two methods 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 viewing it using some type of reporting tool. Figure 40.5 below illustrates NetFlow operation on a Cisco IOS router and how the flow cache is populated:
Figure 40.5 – Basic NetFlow Operation and Flow Cache Population
Referencing Figure 40.5, ingress traffic is received on 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:
- Cisco IOS NetFlow is configured on the device to capture flows to the NetFlow cache.
- NetFlow export is configured to send flows to the Collector.
- 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.
- Those identified flows are exported to the NetFlow Collector server.
- Approximately 30 to 50 flows are bundled together and are typically transported via UDP.
- The NetFlow Collector software creates real-time or historical reports from the data.
Three primary steps are required when configuring Cisco IOS NetFlow, as follows:
1. Configure the interface to capture flows into the NetFlow cache using the ip flow ingress interface 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.
Note from Dario: The ip route-cache flow command will enable flows on the physical interface and all subinterfaces associated with it.
The ip flow ingress command will enable flows on individual subinterfaces, as opposed to all of them on the same interface. This comes in handy when you are not interested in seeing flows on subinterfaces X, Y, and Z, but you do want to see flows on subinterfaces A, B, and C from that same physical interface.
Additionally, with NetFlow v5, the only option was to monitor inbound statistics using the ip flow ingress command.
However, with the release of NetFlow v9, you now have the option to monitor traffic leaving each interface using the ip flow egress command.
NOTE: Effective with Cisco IOS Releases 12.4(2)T and 12.2(18)SXD, the ip route-cache flow command has been replaced by the ip flow ingress command. Effective with Cisco IOS Releases 12.2(25)S, the output of the show running configuration command was modified so that the ip route-cache flow command, as well as the ip flow ingress command, will appear when either command is configured.
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, as follows:
2. Configure the Cisco IOS NetFlow version or format using 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 analyse the exported NetFlow data. Version 5 exports more fields than version 1 does 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.
3. 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 be 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:
R1#config t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#interface Serial0/0 R1(config-if)#ip flow ingress R1(config-if)#end
Following this configuration, the show ip cache flow command can be used to view collected statistics in the flow cache, as illustrated in the output below:
R1#show ip cache flow IP packet size distribution (721 total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .000 .980 .016 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .002 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 IP Flow Switching Cache, 278544 bytes 4 active, 4092 inactive, 56 added 1195 ager polls, 0 flow alloc failures Active flows timeout in 30 minutes Inactive flows timeout in 15 seconds IP Sub Flow Cache, 21640 bytes 4 active, 1020 inactive, 56 added, 56 added to flow 0 alloc failures, 0 force free 1 chunk, 1 chunk added last clearing of statistics never Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec) -------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow TCP-Telnet 2 0.0 34 40 0.0 10.5 15.7 TCP-WWW 2 0.0 9 93 0.0 0.1 1.5 UDP-NTP 1 0.0 1 76 0.0 0.0 15.4 UDP-other 42 0.0 5 59 0.0 0.0 15.7 ICMP 5 0.0 10 64 0.0 0.0 15.1 Total: 52 0.0 7 58 0.0 0.4 15.1 SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts Se0/0 150.1.1.254 Local 10.0.0.1 01 0000 0800 339 Se0/0 10.0.0.2 Local 1.1.1.1 06 C0B3 0017 7 Se0/0 10.0.0.2 Local 10.0.0.1 11 07AF D0F1 1 Se0/0 10.0.0.2 Local 10.0.0.1 11 8000 D0F1 10 Se0/0 150.1.1.254 Local 10.0.0.1 01 0000 0800 271 Se0/0 10.0.0.2 Local 1.1.1.1 06 C0B3 0017 59
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 data format:
R1(config)#interface Serial0/0 R1(config-if)#ip flow ingress R1(config-if)#exit R1(config)#interface FastEthernet0/0 R1(config-if)#ip flow ingress R1(config-if)#exit R1(config)#interface Serial0/1 R1(config-if)#exit R1(config)#ip flow-export version 5 R1(config)#ip flow-export destination 150.1.1.254 5000 R1(config)#exit
Following this configuration, the collected information can then be viewed using an application reporting tool on the NetFlow Collector. Despite the export of data, the show ip cache flow command can still be used to view statistics on the local device, which can be a useful tool when troubleshooting network issues or problem reports.
Troubleshooting Utilising NetFlow Data
A typical enterprise network has thousands of connections generating massive amounts of NetFlow data in only a short period of time. NetFlow data can be transformed into useful graphs and tables that help network administrators understand what is going on inside the network. NetFlow data can assist with the following:
- Improve overall network performance
- Support latency-sensitive applications, such as voice over IP (VoIP)
- Better manage traffic spikes
- Enforce network policies
- Expose traffic patterns that point to malicious activities
NetFlow statistics can also help administrators understand what percentage of network resources is being consumed by each data type at any given time. You can see at a glance how much bandwidth is being used by e-mail, accounting and ERP systems, and other applications, as well as how many users are watching YouTube videos or making Internet phone calls during the work day.
NetFlow data can be presented in an easy to understand format that enables administrators to easily drill down into more details. They can examine traffic flows by user, application, department, conversation, interface, and protocol. Some examples of situations that can be solved using NetFlow data include the following:
- Capacity issues: NetFlow can clearly show what applications use the most bandwidth and when. This information can help in changing the application traffic patterns in order to improve network performance. This can also be applied to user traffic.
- Security issues: NetFlow data can detect unauthorised traffic patterns across the network and can stop the threat before any harm is done to the network.
- VoIP problems (poor quality, for example) can be corrected after being identified using NetFlow analysers. NetFlow reports can show insufficient bandwidth, latency, or jitter issues that affect the VoIP calls.
Section 40 Questions
- What underlying protocol does syslog use?
- The syslog client sends syslog messages to the syslog sever using UDP as the Transport Layer protocol, specifying a destination port of _______.
- The priority of a syslog message represents both the facility and the severity of the message. This number is an ________ -bit number.
- Name the eight Cisco IOS syslog priority levels.
- In Cisco IOS software, the _______ _______ _______ global configuration command can be used to specify the syslog facility.
- Which command do you use to globally enable logging on a router?
- Name the command used to specify the syslog server destination.
- Name the command used to set the clock on a Cisco IOS router.
- On which ports does SNMP operate?
- Name the command you can use to change the NetFlow version.
Section 40 Answers
- UDP.
- 514.
- 8.
- Emergencies, alerts, critical, errors, warnings, notifications, informational, and debugging.
- The logging facility [facility] command.
- The logging on command.
- The logging [address] or logging host [address] command.
- The clock set command.
- UDP 161 and 162.
- The ip flow-export version x global configuration command.
Section 40 Labs
Logging Lab
Configure logging on a Cisco router:
- Choose the logging facility local3: logging facility local2
- Issue the global logging on command
- Choose logging severity informational
- Configure a free syslog server on a PC and connect it to the router
- Issue the logging [address] command to specify the syslog server
- Specify the logging source-interface command
- Verify the show logging command
- Configure the service timestamps log datetime localtime msec show-timezone command
- Verify the syslog messages on the PC
SNMP Lab
Configure SNMP on a Cisco router:
- Configure the SNMP server with the snmp-server host command
- Configure SNMP RO and RW communities using the snmp-server community command
NetFlow Lab
Configure NetFlow on a Cisco router:
- Enable IP flow ingress and egress on a router interface
- Verify the show ip cache flow command after traffic passes the router
- Configure the NetFlow version using the ip flow-export command
- Configure an external NetFlow server using ip flow-export destination