Home > Articles > Certification > Cisco Certification > CCNP

  • Print
  • + Share This
This chapter is from the book

Implementing Path Control Using Cisco IOS IP SLAs

This section examines path control using Cisco IOS IP SLAs. A typical scenario for this solution is Internet branch office connectivity, with connections to two different ISPs, such as the network illustrated in Figure 5-4. In this case, the organization's edge router is configured to perform NAT, and has default routes for outbound traffic to the ISPs; branch offices, especially smaller ones, are not likely to run BGP or other routing protocols toward the ISP. The static default routes are likely to be equal cost, and the Cisco IOS will by default load balance over the links on a per-destination basis. NAT will be applied to the outbound traffic resulting from the load- balancing algorithm.

Figure 5-4

Figure 5-4 A Branch Office Scenario.

In this scenario, the edge router can detect if there is a direct failure on the link to one ISP, and in that case use the other ISP for all traffic. However, if the infrastructure within of one of the ISPs fails and the link to that ISP remains up, the edge router would continue to use that link because the static default route would still be valid.

There are multiple solutions to this issue. One approach is for the branch office router to run a dynamic routing protocol with the ISPs, so that the branch router learns the ISPs' networks in its routing table. The branch router will then be aware of any link failures within the ISPs' network. This solution is impractical for smaller branch offices, and in any case requires interaction and integration with the ISPs. It may, however, be the best solution for critical branch offices or those with large traffic volumes.

Another solution is to use either static routes or PBR, but make them subject to reachability tests toward critical destinations, such as the Domain Name System (DNS) servers within the ISP. If the DNS servers in one of the ISPs go down or are unreachable, the static route toward that ISP would be removed. These reachability tests can be performed with Cisco IOS IP SLAs that probe the DNS servers frequently and that are attached to the static routes.

The tools used for this solution include the following:

  • Object tracking—The Cisco IOS object tracking tracks the reachability of specified objects (in this example, of DNS servers).
  • Cisco IOS IP SLAs probes—The object tracking features can use Cisco IOS IP SLAs to send different types of probes toward the desired objects.
  • Route maps with PBR—To associate the results of the tracking to the routing process, PBR with route maps can be used, allowing options to define specific traffic classes, such as voice, or specific applications.
  • Static routes with tracking options—As an alternative to PBR, you can use static routes with tracking options. This solution is simpler and accommodates scenarios in which you want all outbound traffic to choose outbound exit points similarly.

Using Cisco IOS IP SLAs to Control Path Selection

This section introduces Cisco IOS IP SLAs and describes how this feature is used to control path selection.

Cisco IOS IP SLAs use active traffic monitoring, generating traffic in a continuous, reliable, and predictable manner, to measure network performance.

Cisco IOS IP SLAs, illustrated in Figure 5-5, send simulated data across the network and measure performance between multiple network locations or across multiple network paths. The information collected includes data about response time, one-way latency, jitter (interpacket delay variance), packet loss, voice-quality scoring, network resource availability, application performance, and server response time. In its simplest form, Cisco IOS IP SLAs verify whether a network element, such as an IP address on a router interface or an open TCP port on an IP host, is active and responsive.

Figure 5-5

Figure 5-5 Cisco IOS IP SLAs Measure Network Performance.

Because Cisco IOS IP SLAs are accessible using Simple Network Management Protocol (SNMP), performance-monitoring applications, such as CiscoWorks Internetwork Performance Monitor (IPM) and other third-party Cisco partner performance-management products, can also use them.

Cisco IOS IP SLAs use the Cisco Round-Trip Time Monitor (RTTMON) Management Information Base (MIB) for communication between the external Network Management System (NMS) applications and the Cisco IOS IP SLAs operations running on the Cisco devices.

As an additional feature, SNMP notifications based on the data gathered by a Cisco IOS IP SLAs operation allow the router to receive alerts when performance drops below a specified level and when problems are corrected. These thresholds can trigger additional events and actions.

The following sections detail IP SLAs terminology and operation, before configuration, verification, and examples are provided in later sections.

Cisco IOS IP SLAs Operation

The embedded Cisco IOS IP SLAs measurement capability allows network managers to validate network performance, proactively identify network issues, and verify service guarantees by using active monitoring to generate probe traffic in a continuous, reliable, and predictable manner. This measurement capability also helps create a network that is "performance aware." Using IOS IP SLAs measurements, Cisco network equipment can verify service guarantees, validate network performance, improve network reliability, proactively identify network issues, and react to performance metrics with changes to the configuration and network.

The Cisco IOS IP SLAs feature allows performance measurements to be taken within and between Cisco devices, or between a Cisco device and a host, providing data about service levels for IP applications and services.

Cisco IOS IP SLAs measurements perform active monitoring by generating and analyzing traffic to measure performance between Cisco IOS Software devices or between a Cisco IOS device and a host, such as a network application server. With the IOS IP SLAs feature enabled, a router sends synthetic traffic to the other device, as illustrated in Figure 5-6.

Figure 5-6

Figure 5-6 IP SLAs Take Measurements Between a Cisco Device and Another Cisco Device or a Host.

Cisco IOS IP SLAs Sources and Responders

All the IP SLAs measurement probe operations are configured on the IP SLAs source, either via the command-line interface (CLI) or through an SNMP tool that supports the operation of IP SLAs. The source sends probe packets to the target.

There are two types of IP SLAs operations: those in which the target device is running the IP SLAs responder component (such as a Cisco router), and those in which the target device is not running the IP SLAs responder component (such as a web server or IP host). An IP SLAs responder is a component embedded in a Cisco IOS device that allows that device to anticipate and respond to IP SLAs request packets. A Cisco IOS device can be configured as an IP SLAs responder and will provide accurate measurements without the need for dedicated probes or any complex or per-operation configuration.

The IP SLAs measurement accuracy is improved when the target is an IP SLAs responder, as described in the upcoming "Cisco IOS IP SLAs Operation with Responders" section.

Cisco IOS IP SLAs Operations

An IP SLAs operation is a measurement that includes protocol, frequency, traps, and thresholds.

The network manager configures the IP SLAs source with the target device address, protocol, and User Datagram Protocol (UDP) or Transfer Control Protocol (TCP) port number, for each operation. When the operation is finished and the response has been received, the results are stored in the IP SLAs MIB on the source, and are retrieved using SNMP.

IP SLAs operations are specific to target devices. Operations such as DNS or HTTP can be sent to any suitable computer. For operations such as testing the port used by a database, there might be risks associated with unexpected effects on actual database servers, and therefore IP SLAs responder functionality on a router can be configured to respond in place of the actual database server.

Cisco IOS IP SLAs Operation with Responders

Using an IP SLAs responder provides enhanced measurement accuracy—without the need for dedicated third-party external probe devices—and additional statistics that are not otherwise available via standard Internet Control Message Protocol (ICMP)-based measurements.

When a network manager configures an IP SLAs operation on the IP SLAs source, reaction conditions can also be defined, and the operation can be scheduled to be run for a period of time to gather statistics. The source uses the IP SLAs control protocol to communicate with the responder before sending test packets. To increase security of IP SLAs control messages, message digest 5 (MD5) authentication can be used to secure the control protocol exchange.

The following sequence of events occurs for each IP SLAs operation that requires a responder on the target, as illustrated in Figure 5-7:

  1. At the start of the control phase, the IP SLAs source sends a control message with the configured IP SLAs operation information to IP SLAs control port UDP 1967 on the target router (the responder). The control message includes the protocol, port number, and duration of the operation. In Figure 5-7, UDP port 2020 is used for the IP SLAs test packets.

    If MD5 authentication is enabled, the MD5 checksum is sent with the control message, and the responder verifies the MD5 checksum. If the authentication fails, the responder returns an "authentication failure" message.

  2. If the responder processes the control message, it sends an "OK" message to the source and listens on the port specified in the control message for a specified duration. If the responder cannot process the control message, it returns an error. If the IP SLAs source does not receive a response from the responder, it tries to retransmit the control message. It will eventually time out if it does not receive a response.
  3. If an "OK" message is returned, the IP SLAs operation on the source moves to the probing phase where it sends one or more test packets to the responder to compute response times. In Figure 5-7, the test messages are sent on control port 2020.
  4. The responder accepts the test packets and responds. Based on the type of operation, the responder may add an "in" time stamp and an "out" time stamp in the response packet payload to account for the CPU time spent measuring unidirectional packet loss, latency, and jitter. These time stamps help the IP SLAs source make accurate assessments of one-way delay and processing time in target routers. The responder disables the user-specified port after it responds to the IP SLAs measurements packet or when the specified time expires.
Figure 5-7

Figure 5-7 IP SLAs Operation with a Responder.

Cisco IOS IP SLAs with Responder Time Stamps

Figure 5-8 illustrates the use of time stamps in round-trip calculations in an operation using an IP SLAs responder. The IP SLAs source uses four time stamps for the round-trip time (RTT) calculation.

Figure 5-8

Figure 5-8 Time Stamps in an IP SLAs Operation with a Responder.

The IP SLAs source sends a test packet at time T1.

Because of other high-priority processes, routers might take tens of milliseconds to process incoming packets. For example, the reply to a test packet might be sitting in a queue waiting to be processed. To account for this delay, the IP SLAs responder includes both the receipt time (T2) and the transmitted time (T3) in the response packet. The time stamps are accurate to submilliseconds.

The IP SLAs source subtracts T2 from T3 to determine the delta value—the time spent processing the test packet in the IP SLAs responder. The delta value is subtracted from the overall RTT.

The same principle is applied by IP SLAs source. The incoming time stamp (T4) is taken at the interrupt level to allow for greater accuracy in the RTT calculation. The T4 time stamp, rather than the T5 time stamp (when the packet is processed), is used in the RTT calculation.

The two time stamps taken in the IP SLAs responder also allow one-way delay, jitter, and directional packet loss to be tracked. These statistics are critical for understanding asynchronous network behavior. To calculate these one-way delay measurements, the source and target need to be synchronized to the same clock source, and therefore, the Network Time Protocol (NTP) must be configured on both.

Configuring Path Control Using IOS IP SLAs

This section describes some of the commands used to configure path control using IOS IP SLAs.

The following steps are required to configure Cisco IOS IP SLAs functionality:

  • Step 1. Define one or more IP SLAs operations (or probes).
  • Step 2. Define one or more tracking objects, to track the state of IOS IP SLAs operations.
  • Step 3. Define the action associated with the tracking object.

These steps are detailed in the following sections.

Configuring Cisco IOS IP SLAs Operations

This section describes some of the configuration commands used to define IP SLAs operations.

Use the ip sla operation-number global configuration command (or the ip sla monitor operation-number global configuration command) to begin configuring a Cisco IOS IP SLAs operation and to enter IP SLA configuration mode (or rtr configuration mode). The operation-number is the identification number of the IP SLAs operation you want to configure.

The ICMP echo operation is used to cause ICMP echo requests to be sent to a destination to check connectivity. Use the icmp-echo {destination-ip-address | destination-hostname} [source-ip {ip-address | hostname} | source-interface interface-name] IP SLA configuration mode command (or the type echo protocol ipIcmpEcho {destination-ip-address | destination-hostname} [source-ipaddr {ip-address | hostname} | source-interface interface-name] rtr configuration mode command) to configure an IP SLAs ICMP echo operation. The parameters of these commands are defined in Table 5-3.

Table 5-3. icmp-echo and type echo protocol ipIcmpEcho Commands

Parameter

Description

destination-ip-address | destination-hostname

Destination IPv4 or IPv6 address or hostname.

source-ip {ip-address | hostname} (or source-ipaddr {ip-address | hostname})

(Optional) Specifies the source IPv4 or IPv6 address or hostname. When a source IP address or hostname is not specified, the IP SLAs chooses the IP address nearest to the destination.

source-interface interface-name

(Optional) Specifies the source interface for the operation.

Use the frequency seconds IP SLA configuration submode command (or rtr configuration submode command) to set the rate at which a specified IP SLAs operation repeats. (For example, this command can be entered within the icmp-echo command mode.) The seconds parameter is the number of seconds between the IP SLAs operations; the default is 60.

Use the timeout milliseconds IP SLA configuration submode command (or rtr configuration submode command) to set the amount of time a Cisco IOS IP SLAs operation waits for a response from its request packet. (For example, this command can be entered within the icmp-echo command mode.) The milliseconds parameter is the number of milliseconds (ms) the operation waits to receive a response from its request packet. It is recommended that the value of the milliseconds parameter be based on the sum of both the maximum RTT value for the packets and the processing time of the IP SLAs operation.

After the Cisco IP SLAs operation is configured, it needs to be scheduled. Use the ip sla schedule operation-number [life {forever | seconds}] [start-time {hh:mm[:ss] [month day | day month] | pending | now | after hh :mm:ss}] [ageout seconds] [recurring] global configuration mode command (or the ip sla monitor schedule operation-number [life {forever | seconds}] [start-time {hh:mm[:ss] [month day | day month] | pending | now | after hh:mm:ss}] [ageoutseconds] [recurring] global configuration mode command) to configure the scheduling parameters for a single Cisco IOS IP SLAs operation. The parameters of these commands are defined in Table 5-4.

Table 5-4. ip sla schedule and ip sla monitor schedule Commands

Parameter

Description

operation-number

Number of the IP SLAs operation to schedule.

life forever

(Optional) Schedules the operation to run indefinitely.

life seconds

(Optional) Number of seconds the operation actively collects information. The default is 3600 seconds (1 hour).

start-time

(Optional) Time when the operation starts.

hh:mm[:ss]

Specifies an absolute start time using hour, minute, and (optionally) second. Use the 24-hour clock notation. For example, start time 01:02 means "start at 1:02 a.m.," and start time 13:01:30 means "start at 1:01 p.m. and 30 seconds." The current day is implied unless you specify a month and day.

month

(Optional) Name of the month to start the operation in. If month is not specified, the current month is used. Use of this argument requires that a day be specified. You can specify the month by using either the full English name or the first three letters of the month.

day

(Optional) Number of the day (in the range 1 to 31) to start the operation on. If a day is not specified, the current day is used. Use of this argument requires that a month be specified.

pending

(Optional) No information is collected. This is the default value.

now

(Optional) Indicates that the operation should start immediately.

after hh:mm:ss

(Optional) Indicates that the operation should start hh hours, mm minutes, and ss seconds after this command was entered.

ageout seconds

(Optional) Number of seconds to keep the operation in memory when it is not actively collecting information. The default is 0 seconds (never ages out).

recurring

(Optional) Indicates that the operation will start automatically at the specified time and for the specified duration every day.

Configuring Cisco IOS IP SLAs Tracking Objects

This section examines some of the configuration commands used to define tracking objects, to track the state of IOS IP SLAs operations.

Use the track object-number ip sla operation-number {state | reachability} global configuration command (or the track object-number rtr operation-number {state | reachability} global configuration command) to track the state of an IOS IP SLAs operation, and enter track configuration mode. The parameters of these commands are defined in Table 5-5.

Table 5-5. track ip sla and track rtr Commands

Parameter

Description

object-number

Object number representing the object to be tracked. The range is from 1 to 500.

operation-number

Number used for the identification of the IP SLAs operation you are tracking.

state

Tracks the operation return code.

reachability

Tracks whether the route is reachable.

Use the delay {up seconds [down seconds] | [up seconds] down seconds} track configuration command to specify a period of time to delay communicating state changes of a tracked object. The parameters of this command are defined in Table 5-6.

Table 5-6. delay Commands

Parameter

Description

up

Time to delay the notification of an up event.

down

Time to delay the notification of a down event.

seconds

Delay value, in seconds. The range is from 0 to 180. The default is 0.

Configuring the Action Associated with the Tracking Object

This section describes one of the configuration commands used to define the action associated with the tracking object.

Use the ip route prefix mask {ip-address | interface-type interface-number [ip-address]} [dhcp] [distance] [name next-hop-name] [permanent | track number] [tag tag] global configuration command to establish a static route that tracks an object. The parameters of this command are defined in Table 5-7.

Table 5-7. ip route Command

Parameter

Description

prefix

IP route prefix for the destination.

mask

Prefix mask for the destination.

ip-address

IP address of the next hop that can be used to reach that network.

interface-type interface-number

Network interface type and interface number.

dhcp

(Optional) Enables a Dynamic Host Configuration Protocol (DHCP) server to assign a static route to a default gateway (option 3). Note that you specify the dhcp keyword for each routing protocol.

distance

(Optional) Administrative distance. The default administrative distance for a static route is 1.

name next-hop-name

(Optional) Applies a name to the specified route.

permanent

(Optional) Specifies that the route will not be removed, even if the interface shuts down.

track number

(Optional) Associates a track object with this route. Valid values for the number argument range from 1 to 500.

tag tag

(Optional) Tag value that can be used as a "match" value for controlling redistribution via route maps.

The next section introduces some of the commands used to verify path control using IOS IP SLAs. The section after that illustrates two examples of IOS IP SLAs configuration and verification.

Verifying Path Control Using IOS IP SLAs

This section describes some of the commands used to verify path control using IOS IP SLAs.

Use the show ip sla configuration [operation] command (or the show ip sla monitor configuration [operation] command) to display configuration values including all defaults for all Cisco IOS IP SLAs operations, or for a specified operation. The operation parameter is the number of the IP SLAs operation for which the details will be displayed.

Use the show ip sla statistics [operation-number] [details] command (or the show ip sla monitor statistics [operation-number] [details] command) to display the current operational status and statistics of all Cisco IOS IP SLAs operations, or of a specified operation. The parameters of these commands are defined in Table 5-8.

Table 5-8. show ip sla statistics and show ip sla monitor statistics Commands

Parameter

Description

operation-number

(Optional) Number of the operation for which operational status and statistics are displayed.

details

(Optional) Operational status and statistics are displayed in greater detail.

Examples of Path Control Using Cisco IOS IP SLAs

This section uses two examples to illustrate IOS IP SLAs configuration and verification.

Tracking Reachability to Two ISPs

Figure 5-9 illustrates a scenario in which Customer A is multihoming to two ISPs. Customer A is not using BGP with the ISPs; instead, it is using static default routes. Two default static routes with different administrative distances are configured, so that the link to ISP-1 is the primary link and the link to ISP-2 is the backup link. The static default route with the lower administrative distance will be preferred and injected into the routing table.

Figure 5-9

Figure 5-9 Tracking Reachability to Two ISPs Example Network.

However, if there is a problem with the ISP-1 router or with its connectivity toward the Internet but its interface to Customer A is still up, all traffic from Customer A will still go to that ISP. This traffic may then get lost within the ISP. The solution to this issue is the Cisco IOS IP SLAs functionality, which can be used to continuously check the reachability of a specific destination (such as a provider edge [PE] router interface, the ISP's DNS server, or any other specific destination) and conditionally announce the default route only if the connectivity is verified.

The Cisco IOS IP SLAs configuration of R1 is provided in Example 5-2.

Example 5-2. Cisco IOS IP SLAs Configuration of Router R1 in Figure 5-9

R1(config)#ip sla monitor 11
R1(config-rtr)#type echo protocol ipIcmpEcho 10.1.1.1 source-interface
FastEthernet0/0
R1(config-rtr-echo)#frequency 10
R1(config-rtr-echo)#exit
R1(config)#ip sla monitor schedule 11 life forever start-time now
R1(config)#track 1 rtr 11 reachability
R1(config-track)#exit
R1(config)#ip route 0.0.0.0 0.0.0.0 10.1.1.1 2 track 1
R1(config)#ip sla monitor 22
R1(config-rtr)#type echo protocol ipIcmpEcho 172.16.1.1 source-interface
FastEthernet0/1
R1(config-rtr-echo)#frequency 10
R1(config-rtr-echo)#exit
R1(config)#ip sla monitor schedule 22 life forever start-time now
R1(config)#track 2 rtr 22 reachability
R1(config-track)#exit
R1(config)#ip route 0.0.0.0 0.0.0.0 172.16.1.1 3 track 2

The first step in this configuration defines the probe; probe 11 is defined by the ip sla monitor 11 command. The test defined with the type echo protocol ipIcmpEcho 10.1.1.1 source-interface FastEthernet0/0 command specifies that the ICMP echoes are sent to destination 10.1.1.1 (R2) to check connectivity, with the Fast Ethernet 0/0 interface used as the source interface. The frequency 10 command schedules the connectivity test to repeat every 10 seconds. The ip sla monitor schedule 11 life forever start-time now command defines the start and end time of the connectivity test for probe 11; the start time is now and it will continue forever.

The second step defines the tracking object, which is linked to the probe from the first step. The track 1 rtr 11 reachability command specifies that object 1 is tracked; it is linked to probe 11 (defined in the first step) so that the reachability of the 10.1.1.1 is tracked.

The last step defines an action based on the status of the tracking object. The ip route 0.0.0.0 0.0.0.0 10.1.1.1 2 track 1 command conditionally configures the default route, via 10.1.1.1, with an administrative distance of 2, if the result of tracking object 1 is true. Thus, if 10.1.1.1 is reachable, a static default route via 10.1.1.1 with an administrative distance of 2, is installed in the routing table.

This scenario requires the configuration of two probes, two tracking objects, and two conditionally announced default routes. The second set of configuration commands in Example 5-2 is almost the same as the first set. Probe 22, defined by the ip sla monitor 22 command, defines the test condition for the reachability of the backup ISP destination address 172.16.1.1, using Fast Ethernet 0/1 as the source address. The test is every 10 seconds, from now to forever. Tracking object 2 is related to the second probe, as defined by the track 2 rtr 22 reachability command. The default route configured, via 172.16.1.1, is using a higher administrative distance of 3, because the backup ISP is to be used only if the primary ISP is not available. This default route is offered to the routing table if the result of tracking object 2 is true.

Tracking DNS Server Reachability in the Two ISPs

Figure 5-10 illustrates the network for this example scenario. R3 represents a branch office connected to two ISPs. In this scenario Cisco IOS IP SLAs are used to track the reachability to the DNS servers (with IP addresses 10.0.8.1 and 10.0.8.2) and tie the results to the static default routes on R3. If there is a DNS server failure, the Cisco IOS IP SLAs probes will fail, the static default route to that DNS will be removed, and all traffic will be rerouted toward the other ISP.

Figure 5-10

Figure 5-10 Tracking Reachability to DNS Servers in the Two ISPs Example Network.

The following steps detail the implementation and verification of Cisco IOS IP SLAs in this example:

  • Step 1. Verify reachability to the DNS servers.
  • Step 2. Configure Cisco IOS IP SLAs.
  • Step 3. Verify Cisco IOS IP SLAs operations.
  • Step 4. Configure tracking options.
  • Step 5. Configure static default routes or PBR that are tied to object tracking (the DNS servers).
  • Step 6. Verify dynamic operations and routing changes when the tracked objects fail.

Example 5-3 illustrates the results of the reachability verification tests from R3 to the DNS servers.

Example 5-3. Results of Reachability Tests to DNS Servers from R3

R3#ping 10.0.8.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.8.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/31/36 ms
R3#ping 10.0.8.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.8.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/29/32 ms
R3#

After confirming that the reachability tests are successful, the Cisco IOS IP SLAs are configured. The configuration is shown in Example 5-4. The ip sla monitor 99 command is used to create an ICMP echo probe on R3 to the first DNS server; the operation number 99 is locally significant only to the router. (Note that there are many other types of probes other than the ICMP echo probes that could be created.) The frequency 10 command schedules the connectivity test to repeat every 10 seconds. The probe is scheduled to start now, and to run forever. A second probe, 100, is similarly created to test connectivity to the second DNS server.

Example 5-4. Configuration of Router R3 in Figure 5-10

ip sla monitor 99
 type echo protocol ipIcmpEcho 10.0.8.1
 frequency 10
ip sla monitor schedule 99 life forever start-time now

ip sla monitor 100
 type echo protocol ipIcmpEcho 10.0.8.2
 frequency 10
ip sla monitor schedule 100 life forever start-time now

The IP SLAs configuration is verified next, using the show ip sla monitor configuration command. The partial output is shown in Example 5-5, illustrating the details of the configuration of operation 99. This output confirms that the operation is an echo operation to 10.0.8.1 with a frequency of 10 seconds, and that it has already started (the start time has already passed).

Example 5-5. show ip sla monitor configuration Output on R3

R3(config)#do show ip sla monitor configuration
SA Agent, Infrastructure Engine-II
Entry number: 99
Owner:
Tag:

 Type of operation to perform: echo 
 Target address: 10.0.8.1           
Request size (ARR data portion): 28
Operation timeout (milliseconds): 5000
Type of Service parameters: 0x0
Verify data: No

 Operation frequency (seconds): 10                    
 Next Scheduled Start Time: Start Time already passed 
Group Scheduled: FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
Number of history Lives kept: 0
Number of history Buckets kept: 15
—-More—-

The show ip sla monitor statistics command is used next, to display the number of successes, failures, and the results of the latest operations. The output is shown in Example 5-6, and it confirms that operation 99 has succeeded 16 times already, had no failures, and the last operation returned an "OK" result. Operation 100 has succeeded 15 times, had no failures, and its last operation also returned an "OK" result.

Example 5-6. show ip sla monitor statistics Output on R3

R3(config)#do show ip sla monitor statistics
Round trip time (RTT)   Index 99 
         Latest RTT: 20 ms
Latest operation start time: *18:07:10.306 UTC Fri May 24 2002

 Latest operation return code: OK 
 Number of successes: 16          
 Number of failures: 0            
Operation time to live: Forever

Round trip time (RTT)   Index 100 
         Latest RTT: 19 ms
Latest operation start time: *18:07:12.006 UTC Fri May 24 2002

 Latest operation return code: OK 
 Number of successes: 15          
 Number of failures: 0            
Operation time to live: Forever

R3(config)#

The next step is to configure tracking objects, as illustrated in Example 5-7. The first tracking object is tied to IP SLAs object 99 and has 10 seconds of down delay and 1 second of up delay, representing the level of sensitivity to changes of tracked objects. The delay helps to alleviate the affect of flapping objects, those that are going down and up rapidly. In this case, if the DNS server fails momentarily and comes back up within 10 seconds, there is no impact. The ip route command creates a static default route via 192.168.2.2 (R1) that appears or disappears, depending on the success or failure of the IP SLAs operation. Notice that this command reference the tracking object number 1, which in turn reference IP SLAs operation number 99.

The second tracking object is tied to IP SLAs object 100 and has a similar configuration.

Example 5-7. Tracking Object Configuration of Router R3 in Figure 5-10

track 1 rtr 99 reachability
 delay down 10 up 1
ip route 0.0.0.0 0.0.0.0 192.168.2.2 track 1

track 2 rtr 100 reachability
 delay down 10 up 1
ip route 0.0.0.0 0.0.0.0 192.168.1.2 track 2

Example 5-8 shows the static routes in the IP routing table. This output confirms that both static default routes currently appear in the routing table.

Example 5-8. Routing Table on Router R3

R3#show ip route static
S*   0.0.0.0 0.0.0.0 [1/0] via 192.168.2.2
                             via 192.168.1.2

To examine the routing behavior, IP routing debugging is enabled on R3, with the debug ip routing command. The DNS address on R2 is shut down. (Recall that in this example, the DNS address is simulated by interface loopback 0 on R2; thus a shutdown command on this interface is all that is required.)

The debug output on R3 is shown in Example 5-9. The EIGRP route to 10.0.8.2 is immediately deleted, and there are now no routes to 10.0.8.2. This is the object being tracked with the track 2 command; it tracks reachability to IP SLAs object 100, which is an ICMP echo to 10.0.8.2. After about 10 seconds, the value specified in the delay command, the static default route via 192.168.1.2 (R2) is deleted.

Example 5-9. debug ip routing Output on R3

R3#
3w6d: RT: delete route to 10.0.8.2 via 192.168.1.2, eigrp metric [90/156160]
3w6d: RT: SET_LAST_RDB for 10.0.8.2 255.255.255.255
  OLD rdb: via 192.168.1.2, FastEthernet0/1

3w6d: RT: no routes to 10.0.8.2
3w6d: RT: NET-RED 10.0.8.2 255.255.255.255
3w6d: RT: delete subnet route to 10.0.8.2 255.255.255.255
3w6d: RT: NET-RED 10.0.8.2 255.255.255.255
R3#
3w6d: RT: del 0.0.0.0 via 192.168.1.2, static metric [1/0]
3w6d: RT: NET-RED 0.0.0.0 0.0.0.0
R3#
3w6d: RT: NET-RED 0.0.0.0 0.0.0.0
R3#

Debugging is disabled, and the statistics are viewed again, using the show ip sla monitor statistics command, as displayed in Example 5-10. This output confirms that there have been 11 failures on the IP SLAs object 100; these are failures in the ICMP echo to 10.0.8.2. The latest return code is "Timeout."

Example 5-10. show ip sla statistics Output on R3

R3#show ip sla monitor statistics
<Output omitted>
Round Trip Time (RTT) for              Index 100
         Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: *17:29:26.572 UTC Sun Aug 2 2009
 Latest operation return code: Timeout 
Number of successes: 80
 Number of failures: 11 
Operation time to live: Forever


R3#

The static routes in the IP routing table now are shown in Example 5-11. This output confirms that only one static default remains, via 192168.2.2 (R1).

Example 5-11. show ip route static Output on R3

R3#show ip route static
S*   0.0.0.0 0.0.0.0 [1/0] via 192.168.2.2
R3#

To examine the routing behavior when connectivity to the R2 DNS is restored, IP routing debugging is enabled on R3 again, with the debug ip routing command, and the DNS address on R2 is enabled by performing a no shutdown command on the loopback 0 interface on R2.

The debug output on R3 is shown in Example 5-12. The EIGRP route to 10.0.8.2 comes up, and almost immediately the default static route via 192.168.1.2 (R2) comes up.

Example 5-12. debug ip routing Output on R3

3w6d: RT: SET_LAST_RDB for 10.0.8.2 255.255.255.255
  NEW rdb: via 192.168.1.2

3w6d: RT: add 10.0.8.2 255.255.255.255 via 192.168.1.2, eigrp metric [90/156160]
3w6d: RT: NET-RED 10.0.8.2 255.255.255.255
R3#
3w6d: RT: add 0.0.0.0 0.0.0.0 via 192.168.1.2, static metric [1/0]
3w6d: RT: NET-RED 0.0.0.0 0.0.0.0
3w6d: RT: NET-RED 0.0.0.0 0.0.0.0
R3#
3w6d: RT: NET-RED 0.0.0.0 0.0.0.0
R3#

The routing table now is shown in Example 5-13; both static default routes are there. Full connectivity has been restored.

Example 5-13. show ip route static Output on R3

R3#show ip route static
S*   0.0.0.0 0.0.0.0 [1/0] via 192.168.2.2
                             via 192.168.1.2

An alternative solution for this example network, using PBR, is presented at the end of the next section, after PBR is detailed.

In summary, there are many possibilities available with object tracking and Cisco IOS IP SLAs. As shown in these examples, you can base a probe on reachability, changing routing operations and path control based on the ability to reach an object. You can also use Cisco IOS IP SLAs with Cisco IOS Optimized Edge Routing (OER) to allow paths to be changed based on network conditions such as delay, load, and so forth. (Cisco IOS OER allows the best exit path to be selected, based on a defined policy, and is described briefly in the "Cisco IOS Optimized Edge Routing" section, later in this chapter.)

In deploying the Cisco IOS IP SLAs solution, the impact of the additional probe traffic being generated should also be considered, including how that traffic affects bandwidth utilization and congestion levels. Tuning the configuration (for example with the delay and frequency commands) becomes critical to mitigate possible issues related to excessive transitions and route changes in the presence of flapping tracked objects.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020