You will require a deeper understanding of SNMP than ever before for the new CCNA exam. After your initial configurations, you will configure your network for QoS and logging. For the exam, you must know these topics in detail, all the available options and differences between them. We cover advanced SNMP in our CCNP ENSARI course.
Learn SNMP – Simple Network Management Software
SNMP is an Application Layer protocol that operates using UDP ports 161 and 162 to remotely configure, monitor, and manage network devices, including routers, switches, and servers.
Let’s examine a few examples of the parameters monitored by an NMS (graphical view) via SNMP. Figure 20.1 below illustrates a sample report for interface utilization on a network device:
FIG 20.1 – SNMP interface utilization example
Figure 20.2 below illustrates a sample report for CPU parameters (utilization, temperature, and fan) on a network device:
FIG 20.2 – SNMP CPU monitoring example
SNMP uses the concept of agents, which is software running on a network device that collects and stores information about the system in an agreed format called the management information base (MIB).
The MIB can be queried by the manager, which is usually a dedicated server configured to report on network health and issues to allow for preemptive troubleshooting and baselining. The server will run SNMP software as part of the Network Management System (NMS), such as SolarWinds or Cisco Prime. The manager collects the data, and the agents provide the manager with the data. The messages between the manager and the agents are referred to as “sets” and “gets”.
Figure 20.3 below demonstrates what has been discussed thus far:
FIG 20.3 – SNMP
The MIB structure features tree leaves/nodes referred to as Object Identifiers (OIDs). OIDs can be represented by names or numbers, such as 1.5.6. SNMP is extensible inasmuch that it is flexible enough for vendors to create their own OIDs specific to their own devices (see Figure 20.4 below).
FIG 20.4 – MIB structure
SNMP uses several message types in order to operate. These messages are called Protocol Data Units (PDUs) and include:
- GetRequest
- GetNextRequest
- GetBulkRequest
- SetRequest
- InformRequest
- Trap
- Response
The Get messages are used to retrieve certain information from a network device. Say, for example, that you wanted to check the CPU usage on a Cisco router. There is a specific OID for the CPU for that model of router, and the SNMP manager sends a Get request to the agent on the router to get the value at a certain time or over a period of time (see Figure 20.5 below).
FIG 20.5 – SNMP Get request
Set Request messages can change the value of a certain parameter, such as, set an interface to shutdown mode, without you having to physically attend to or console/SSH into the device (see Figure 20.6 below).
FIG 20.6 – SNMP Set request
Inform Request messages are intended for manager-to-manager communication (see Figure 20.7 below). This type of message requires an acknowledgement.
FIG 20.7 – SNMP Inform request
Trap messages are unsolicited and usually go unacknowledged (see Figure 20.8 below). An example of this is a device reporting that an interface has gone down, but it could also be a high CPU usage warning or a low free hard disk warning.
FIG 20.8 – SNMP Trap message
Response messages act as an acknowledgement as well as contain the requested information (see Figure 20.9 below).
FIG 20.9 – SNMP Response message
SNMP has undergone updates over the years. SNMPv1 worked in plain text, which was updated in SNMPv2 but was not adopted. Versions 2c and 2u addressed some v2 shortcomings—2c uses community-based authentication and 2u uses user-based authentication.
The latest version in use is SNMPv3, which greatly improves on two security shortfalls— message security and access control. V2 uses a user-based security model for access control featuring integrity, authentication (hash-based MD5 or SH1), and encryption (DES 56). SNMPv3 uses the view-based access control model, which defines which group(s) can access which types of information per device.
Configuring SNMP
Cisco IOS supports SNMPv1, v2c, and v3. In configuring an SNMP community, there are a few optional steps such as restricting manager access using an ACL and sending traps and informs to the manager station.
The output below configures two community strings. These define the relationship between the management station and the agent running on the device. RO indicates read only, and RW indicates read write for the MIB objects available to the configured community. An optional step is to restrict access to the SNMP management station.
R1(config)#snmp-server community RO)passwrd ro
R1(config)#snmp-server community RW)passwrd rw
The output below defines the community access string:
R1(config)#access-list 10 permit host 10.0.0.100
R1(config)#snmp-server community RW)passwrd rw 10
The output below shows the versions of SNMP that can be applied. It configures both traps and informs to be sent to the SMNP manager and enables traps.
R1(config)#snmp-server host 10.0.0.100 traps version ?
1 Use SNMPv1
2c Use SNMPv2c
3 Use SNMPv3
R1(config)#snmp-server host 10.0.0.100 traps version 2c PASSWD
R1(config)#snmp-server host 10.0.0.100 informs ver 2c PASSWD
R1(config)#snmp-server enable traps
As shown in the output below, the types of traps to be sent can be specified; however, if they are not, the router will send all supported traps:
R1(config)#snmp-server enable traps ?
aaa_server Enable SNMP AAA Server traps
bgp Enable BGP traps
config Enable SNMP config traps
config-copy Enable SNMP config-copy traps
cpu Allow cpu related traps
[output truncated]
Configuring SNMPv3 requires configuring groups and users with passwords for access to security mechanisms.
- Configure the group(s):
R1(config)#snmp-server group RW_GRP v3 priv write WR_VIEW
R1(config)#snmp-server group RO_GRP v3 auth
In the configuration above, the group RW_GRP is configured to use user authentication, while priv indicates that messages are authenticated and encrypted.
- Configure the users:
R1(config)#snmp-server user SNMPUSER RW_GRP v3 auth sha cisco1 priv des cisco1
*Mar 1 00:30:05.207: Configuring snmpv3 USM user, persisting snmpEngineBoots. Please Wait…
R1(config)#snmp-server user SNMPUSER2 RO_GRP v3 auth md5 cisco123
- Verify SNMP:
R1#show snmp community
Community name: ILMI
Community Index: cisco0
Community SecurityName: ILMI
storage-type: read-only active
Community name: RO)passwrd
Community Index: cisco2
Community SecurityName: RO)passwrd
storage-type: nonvolatile active
Community name: RW)passwrd
Community Index: cisco3
Community SecurityName: RW)passwrd
storage-type: nonvolatile active access-list: 10
Community name: PASSWD
Community Index: cisco4
Community SecurityName: PASSWD
storage-type: nonvolatile active
R1#show snmp host
Notification host: 10.0.0.100 udp-port: 162 type: inform
user: PASSWD security model: v2c
Notification host: 10.0.0.100 udp-port: 162 type: trap
user: PASSWD security model: v2c
R1#show snmp group
groupname: ILMI security model:v1
readview: *ilmi writeview: *ilmi
notifyview: <no notifyview specified>
row status: active
groupname: ILMI security model:v2c
readview: *ilmi writeview: *ilmi
notifyview: <no notifyview specified>
row status: active
groupname: PASSWD security model:v1
readview: <no readview specified> writeview: <no writeview specified>
notifyview: *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF.F
row status: active
groupname: PASSWD security model:v2c
readview: <no readview specified> writeview: <no writeview specified>
notifyview: *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF.F
row status: active
groupname: RO_GRP security model:v3 auth
readview: v1default writeview: <no writeview specified>
notifyview: <no notifyview specified>
row status: active
[output truncated]It’s worth noting that adding SNMP to network devices will increase CPU load, so you should test it or get advice from Cisco TAC before implementing it on your network.
“The reason behind the High CPU usage can be caused by the Network Management Server (SNMP Server) like HP Openview querying for the Routing Tables and ARP tables to learn about other networks or querying for certain MIBs which can be resource intensive” (© DebianAdmin.com).
Syslog
Syslog is a standard used to generate and collect informational messages; to use the vernacular, it’s a system for logging messages.
Routers and switches (as well as many other network devices) maintain timestamped logs reporting events that may be of interest to us as network administrators. Depending on the device, it can report these events in real time (using debugging commands), send the logs to another network device, or record them in NVRAM to be examined at a convenient time. To enable the router to record the logs in NVRAM, you would use the logging buffered command.
Syslog is defined in RFC 5424, and it is supported on a wide range of devices and platforms. Because of this, syslog can be used to integrate log data from many different types of systems into a central repository. It is a lightweight client/server event notification protocol that initially worked over UDP (User Datagram Protocol) but now uses TCP (Transmission Control Protocol).
Syslog servers (also called syslog daemons) are entities that listen to syslog messages generated by network devices. Usually, data is sent in clear text but mechanisms have been developed that secure syslog data using Transport Layer Security (TLS), which is the successor of Secure Sockets Layer (SSL) encryption. Syslog uses port number 514. The advantages of logging to an actual server (rather than a router) include saving router resources (and space) and the ability to interrogate historic logs and alerts in detail.
RFC 5424 ruled that syslog over UDP is now obsolete and that syslog must now support TLS using 6514 by default, so firewalls should be configured to pass packets for this port.
The syslog standard defines eight severity levels. On Cisco routers, the default is Level 7 (Debug):
- 0 (Emergency) – This is a very urgent notification that requires immediate attention. The system is unusable when such a message is generated.
- 1 (Alert) – This is an urgent notification, announcing to the system administration that action must be taken immediately to correct a problem.
- 2 (Critical) – This message indicates a failure that should be corrected as soon as possible but is usually associated with a secondary system, such as the loss of a backup connection.
- 3 (Error) – This message indicates a non-urgent failure.
- 4 (Warning) – Warning messages are related to issues that might lead to an error if action is not taken.
- 5 (Notice) – This indicates an event that is unusual but is not an error condition. No immediate action required.
- 6 (Informational) – These are normal operational status messages.
- 7 (Debug) – This information is useful for developers or for network engineers during a troubleshooting process.
It’s worth noting that whichever level you choose to monitor, the levels above it will also be included; for example, if you choose Level 3 (Error), Levels 2 through 0 will also be monitored.
Mini-lab – Cisco IOS Syslog Configuration
When configuring syslog in a network environment, the first thing you should do is make sure that you have a consistent time/clock setting on all network devices. This will be very useful when trying to correlate log messages from multiple devices when analyzing an event that happened in the network at a specific time.
As discussed earlier, on a Cisco device, you have two ways of configuring the clock. Manual clock configuration was demonstrated earlier in the guide. You can also configure the time zone:
- Manual clock configuration
- NTP (Network Time Protocol)
R1(config)#clock timezone CST -4
Or use NTP:
R1(config)#ntp server 10.10.10.100
After you have made sure that the correct time and clock settings are configured on all network devices involved in the log collecting process, the next step is to enable the timestamps service on the devices. This permits the system to associate a timestamp with each generated syslog message.
 |
The timestamp feature should be on by default, but here is how you enable it if it’s been deactivated by another network administrator:
R1(config)#service timestamps |
As with all the commands in this guide, there are several configuration options but these fall outside the CCNA exam. If you want to know more about the other permutations, you can find this information at Cisco.com. Next, specify the host that will collect the log messages; in other words, the syslog server. You need to install the syslog server on a server or workstation with a fixed IP address.
R1(config)#logging host 10.9.9.10
Next, the router needs to know what kinds of messages should be exported to the syslog server. This is accomplished by defining the severity level (configured severity level + all higher severity level messages are sent):
R1(config)#logging trap ?
[0-7] Logging severity level
alerts Immediate action needed (severity=1)
critical Critical conditions (severity=2)
debugging messages (severity=7)
emergencies System is unusable (severity=0)
errors Error conditions (severity=3)
informational messages (severity=6)
notifications Normal but significant conditions (severity=5)
warnings Warning conditions (severity=4)
[cr]
R1(config)#logging trap informational
You can also specify a syslog facility to be used. 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. By default, Cisco IOS devices use facility local7 (Level 7 – Debug) to send syslog messages.
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
R1(config)#logging facility local1
You can verify the syslog configuration using the following command:
R1#show logging
Syslog logging: enabled (12 messages dropped, 0 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)
No Active Message Discriminator.
No Inactive Message Discriminator.
Console logging: level debugging, 55 messages logged,
xml disabled, filtering 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
Persistent logging: disabled
No active filter modules.
ESM: 0 messages dropped
Jun 1 10:26:14.467: %SYS-6-LOGGINGHOST_STARTSTOP: Logging to host 10.9.9.10 port 514 started – CLI initiated
Trap logging: level informational, 58 message lines logged
Logging to 10.9.9.10 (udp port 514, audit disabled,
authentication disabled, encryption disabled, link up),
2 message lines logged,
0 message lines rate-limited,
0 message lines dropped-by-MD,
xml disabled, sequence number disabled
filtering disabled
Please do try all of these commands on a router. Reading about them is simply not enough to get them to sink in.
[END OF MINI-LAB]Introduction to QoS
A wide range of tools to manage and optimize network traffic has been developed over the years, of which most can be categorized under the umbrella term QoS (Quality of Service). Although QoS is not designed to overcome poor network design or provisioning, it can help overcome congestion issues.
Cisco guides covering QoS range from 760 to over 1,000 pages—covering configuration as well as end-to-end QoS network design. In this guide, QoS will be covered at a high level so that you can have a general discussion about it with other engineers. For the CCNA exam, you will not be tested on any QoS configurations; however, you will be tested on a general understanding of the concepts, which will be discussed here.
QoS is divided into three broad groups:
- Classification and Marking Traffic
- Congestion Management and Avoidance
- Packet Shaping, Policing, and Link Fragmentation
Classifying and marking traffic helps to simplify the job of other QoS tools by marking the packet in either the DiffServ Code Points (DSCPs) field or the IP Precedence (IPP) field, as illustrated in Figure 20.10 below, which is an IPv4 packet:
FIG 20.10 – Classifying and marking traffic
Congestion management (also referred to as queuing) is the process where switches or routers manage packets (or frames) as they wait to exit an interface. Congestion avoidance is the process that decides if or when packets should be dropped after the queue becomes full. Types of queuing include Class-Based Weighted Fair Queueing (CBWFQ) and Low Latency Queueing (LLQ). The output on my router below shows that it is using Weighted Fair queuing:
R1#show queueing int s0/0
Interface Serial0/0 queueing strategy: fair
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/0/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1158 kilobits/sec
Traffic (packet) shaping tools delay traffic from leaving an interface to prevent the configured traffic profile from being breached.
As we all know, network traffic is not always uniform. Your network can experience outages or spikes in traffic at certain times of the day or days of the week. As a network administrator, you will often hear complaints from users that “the network is slow.” Of course, this could just be an application on their PC causing high CPU usage or a poor design. There is a mind-bogglingly huge array of possible causes of slow network performance, and the problem can often disappear as soon as it appeared. These transient problems can be among the hardest to troubleshoot.
QoS is all about service availability. You may have heard of the five 9s rule, which is 99.999% network uptime. That gives you only five minutes of unplanned downtime per year. If you gave HTTP traffic the same priority as video conferencing, then you would jeopardize the availability of the video traffic. Relying on built-in dynamic buffers for voice or video over IP may not be sufficient, so QoS gives you a more deterministic network.
QoS is a means to provide different levels of service to various types of network traffic as determined by the network administrator. An example of this is a banking network that may need to give high priority to a special application used to manage transactions or customer data. Used correctly, QoS technologies will make the convergence of voice, video, and data transparent to network users. It can even monitor the network for threats, marking abnormal traffic to be dealt with by other appliances.
Figure 20.11 below shows a simple home network before and after QoS is applied:
FIG 20.11 – Before and after QoS
Although end users will only judge the network quality by its speed, our perspective as network administrators is far more granular. For us, the quality of a network is determined by the four factors below:
- Bandwidth (speed and capacity of a link)
- Delay (time between packets sent and received)
- Jitter/Delay variation (difference between delay in packets)
- Packet loss (normally due to congestion)
QoS aims to affect network quality by managing all four of the factors above (if required). QoS solutions can be broadly divided into the following categories (illustrated with the analogy of mailing a package at the post office):
- Classification/Marking (placing a “Fragile” sticker on the package)
- Congestion Management (paying for priority service/delivery over other packages)
- Policing and Shaping (size restrictions, the package may have to be split into smaller sizes for mailing)
- Congestion Avoidance
- Link-efficiency Mechanisms
Only a few of these are mentioned in the Cisco CCNA exam syllabus, which will be the ones of particular focus here. Some of the tools such as setting IP precedence bits in the packet do not fit into the category of congestion avoidance or management but are still included in the blanket term QoS.
QoS Classification
As mentioned briefly above, classification deals with the identification of the types of traffic flowing through your network so that you can apply different service levels to them. The criteria can be a particular destination IP, source/destination port, or other factors.
Cisco IOS QoS provides a few methods to classify traffic, including:
- Access control lists (ACLs) – list of rules to permit or deny traffic.
- Policy-based routing (PBR) – packets forwarded based on defined policies.
- Committed access rate (CAR) – traffic on interface limited according to certain criteria.
- Network-based application recognition (NBAR) – inspects packets to recognize a dataflow.
Traffic can be classified and marked (see below) at several layers, from 2 to 7, by examining the packet.
QoS Marking
Marking allows devices along each hop in the network to act according to the mark, as opposed to inspecting each individual packet. The packet is marked at the source rather than at each hop.
There are a few options for marking that are shown in Figure 20.12 below. The first two operate at layer 2 and the last three at layer 3:
- 1Q Class of Service (CoS) bits
- Multiprotocol Label Switching Experimental (MPLS EXP) bits
- IP Precedence (IPP) bits
- Differentiated Services Code Points (DSCPs)
- IP Explicit Congestion bits
Figure 20.12 below shows the part of the IP packet used for marking:
FIG 20.12 – QoS marking
The higher the number, the higher the priority, so voice traffic will be marked 5 by default and normal network data will be marked 1 or 2. The RFC was updated (by RFC 2474) to make the first six bits of the Type of Service (ToS) byte (8 bits) designated as the Differentiated Service field. This field contains the DSCPs, providing up to 64 different traffic classes. The last two bits of the ToS are for IP explicit congestion (which indicates whether there is congestion in the network).
QoS Differentiated Services Architecture
The DiffServ architecture was defined in RFC 2475. The Cisco QoS toolset helps network administrators conform to the RFC. RFC 2474 defines the DS field in IPv4 and IPv6 packet headers.
DiffServ utilizes the concept of traffic classification whereby each packet is put into a limited number of traffic classes. Each of these classes can then be managed differently, giving high priority to some and best-effort to others. DiffServ employs the concept of per-hop behavior (PHB), which defines the policy and priority applied to the packet per router (or hop) in a DiffServ network.
Most QoS implementations use the differentiated services architecture listed below. The DS field determines the per-hop packet behavior.
- Default forwarding – best-effort traffic delivery
- Assured forwarding – four class and three drop preferences
Assured forwarding (AF) gives assured delivery under certain circumstances. Delivery is assured as long as the traffic does not exceed a prescribed rate. The four AF classes are defined by the IETF, and within each class, packets are assigned a drop preference, from low to medium and then high. The higher the precedence, the more likely the packet will be dropped. For example, AF23 would be dropped before AF22, and AF22 packets would be dropped before AF21, and so on (see Table 20.1 below).
Table 20-1 – Assured forwarding
| Drop Preference | Class 1 | Class 2 | Class 3 | Class 4 |
| Low drop probability | AF11 | AF21 | AF31 | AF41 |
| Medium drop probability | AF12 | AF22 | AF32 | AF42 |
| High drop probability | AF13 | AF23 | AF33 | AF43 |
Table 20-2: Formula to calculate DSCP value from AFyx: 8y + 2x
| Example 1 | DSCP value of AF11 = 8(1) + 2(1) = 10 |
| Example 2 | DSCP value of AF43 = 8(4) + 2(3) = 38 |
Other per-hop behaviors include:
- Expedited forwarding – low-loss, low-delay, and low-jitter services; DSCP value 46 (e.g., voice).
- Class selector – backward compatibility with IP Precedence.
QoS Trust Boundary
Device trust is a feature of QoS. The question it raises is, at which point in the network can devices start trusting the markings they see in packets?
If all devices are trusted, in theory, a smart user could set all of his or her network traffic with a high priority, giving this traffic preferred network access. Figure 20.13 below shows some of your options, depending on whether you have voice phones or whether your Layer 2 switches support various QoS options.
FIG 20.13 – QoS trust boundary options
Any QoS tags will be applied and also removed at the edge of the administrative domain.
QoS Solutions
Congestion simply means that traffic is arriving at a faster rate than the network can handle. This is often easier to think of in terms of interfaces, where traffic is arriving on one interface faster than it can be sent out of another interface on the same device.
In normal operations, packets are received at one interface and sent out of another. In times of congestion, what should the device do? Drop the packet, or perhaps store it in a queue of some sort? This then begs the following questions:
- How many queues should exist?
- How should the packets be placed in the queues?
- What sort of algorithm should be used to send the packets out of the queues?
For the first question, if there are different queues, different policies can be applied to each queue, such as a high and low priority queue. Policing and marking can help with the second question, with marking determining which queue the packet is placed in. The scheduling algorithm deals with the last question. Cisco IOS QoS congestion management tools include the following:
- Low Latency Queuing (LLQ) – strict priority servicing; packets in this queue have priority over packets in any other queue. This queue would be used for voice and streaming video.
- Weighted Fair Queuing (WFQ) – guaranteed a certain amount of bandwidth for different queues.
FIG 20.14 – QoS queuing
QoS Policing and Shaping
Policing and shaping are somewhat related. Policing ensures that traffic conforms to a certain rate. If the rate is exceeded, then it can be either dropped or reclassified with a lower priority. Cisco IOS policing tools include committed access rate (CAR) and the traffic policing feature. Policing works in both inbound and outbound directions.
With traffic shaping, excess traffic is held in a queue or buffer, and the excess is released at set rates. Shaping IOS tools include generic traffic shaping (GTS), class-based shaping, and Frame Relay Traffic Shaping (FRTS). Shaping works only in the outbound direction.
Both types of tools are illustrated in Figure 20.15 below:
FIG 20.15 – QoS policing vs shaping
We covered two important syllabus subjects earlier—routing metrics and administrative distances—because they were a better fit for basic IP routing technologies.
After STP issues, the highest number of support calls, we dealt with at Cisco TAC, from Cisco experts were about managing IOS files and recovering lost passwords. Perhaps because it’s such an apparently simple subject it is ignored, but if you think about it, losing the IOS file or forgetting the configuration password ranks as a network emergency. For this reason, you would do well to learn the subjects in this chapter by heart.
ICMP Echo-based IP SLA
The IP Service Level Agreement (IP SLA), which you may have already come across at work, is a document specifying an agreed level of service between the customer and the service provider. Cisco IP SLA is used to measure network performance, including jitter, delay, connectivity, and packet loss. It does this by simulating various types of traffic on the network between the source and the destination. IP SLAs collect a subset of the following by way of performance metrics:
- Delay (both round-trip and one-way)
- Jitter (directional)
- Packet loss (directional)
- Packet sequencing (packet ordering)
- Path (per hop)
- Connectivity (directional)
- Server or website download time
IP SLA operates at Layer 2, is built into Cisco IOS, and consists of IP SLA Source and IP SLA Responder. It can also be accessed by SNMP services such as SolarWinds. Figure 20.16 below demonstrates an example of an IP SLA set up:
FIG 20.16 – IP SLA
One type of IP SLA traffic that can be generated, for example, is ICMP echo (see Figure 20.17 below). IP SLA can generate a multitude of pings over a specified amount of time that can determine both success or failure, as well as round-trip time (RTT), providing valuable information.
FIG 20.17 – ICMP echo
One of the most powerful features of IP SLA is that it not only provides real-time information but also presents historical data of network performance. In Figure 20.17 above, the router has been configured to send ICMP echos to monitor the server. Although configuration is beyond the scope of the exam, some common show commands are displayed below:
R1#show ip sla statistics
Round Trip Time (RTT) for Index 1
Latest RTT: 44 milliseconds
Latest operation start time: *00:05:11.287 UTC Fri Mar 1 2002
Latest operation return code: OK
Number of successes: 19
Number of failures: 1
Operation time to live: 3499 sec
R1#show ip sla application
IP Service Level Agreements
Version: Round Trip Time MIB 2.2.0, Infrastructure Engine-II
Time of last change in whole IP SLAs: *00:03:31.287 UTC Fri Mar 1 2002
Estimated system max number of entries: 1490
Estimated number of configurable operations: 1489
Number of Entries configured: 1
Number of active Entries: 1
Number of pending Entries: 0
Number of inactive Entries: 0
IP SLA can be used to verify service levels and outsourced SLAs, measure network performance, and perform network baseline assessments, as well as verify QoS and help troubleshoot network issues.
End of Chapter Questions
Please visit https://www.howtonetwork.com/ccnasimplified to take the free Chapter 20 exam.
Chapter 20 Labs
Lab 1: Syslog
The physical topology is shown in Figure 20.18 below:
FIG 20.18 – Syslog lab
Lab Exercise
Your task is to configure syslog functionality on a single router (R1).
Purpose
You need to learn how to configure router logging functionality. This is a very commonly used tool for monitoring network devices.
Lab Objectives
- Configure the logging facility.
- Globally enable logging and select severity.
- Configure a logging server.
- Verify logging functionality.
Lab Walk-through
R1(config)#logging facility local2
R1(config)#logging 192.168.0.10
R1(config)#logging trap informational
R1(config)#logging buffered informational
R1(config)#do show logging
Syslog logging: enabled (12 messages dropped, 0 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)
No Active Message Discriminator.
No Inactive Message Discriminator.
Console logging: level debugging, 16 messages logged, xml disabled, filtering disabled
Monitor logging: level debugging, 0 messages logged, xml disabled, filtering disabled
Buffer logging: level informational, 0 messages logged, xml disabled, filtering disabled
Logging Exception size (4096 bytes)
Count and timestamp logging messages: disabled
Persistent logging: disabled
No active filter modules.
ESM: 0 messages dropped
Trap logging: level informational, 20 message lines logged
Logging to 192.168.0.10 (udp port 514, audit disabled,
authentication disabled, encryption disabled, link down),
0 message lines logged,
0 message lines rate-limited,
0 message lines dropped-by-MD,
xml disabled, sequence number disabled
filtering disabled
Log Buffer (4096 bytes):
