IP Service-Level Agreement ccsp coaching center in delhi

Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
 Call: +91-9654672192

The IOS IP Service-Level Agreement (IP SLA) feature measures the ongoing behavior of
the network. The measurement can be as simple as using the equivalent of a ping to determine
if an IP address responds, or as sophisticated as measuring the jitter (delay variation)
of VoIP packets that flow over a particular path. To use IP SLA, an engineer configures IP
SLA operations on various routers, and the routers will then send packets, receive responses,
and gather data about whether a response was received, and the specific characteristics
of the results, such as delay and jitter measurements.
IP SLA primarily acts as a tool to test and gather data about the network. Network management
tools can then collect that data and report whether the network reached SLAs for
the network. Many network management tools support the ability to configure IP SLA
from the management tools’ graphical interfaces. When configured, the routers gather the
results of the operations, storing the statistics in the IOS RTTMON MIB. Management applications
can later gather the statistics from this MIB on various routers and report on
whether the business SLAs were met based on the gathered statistics. For example, you
can use the Cisco Works Internetwork Performance Monitor (IPM) feature to configure
and monitor the data collected using IP SLA operations.
So, why bother with a pure network management feature in this book focused on IP routing?
Well, you can configure static routes and PBR to use IP SLA operations, so that if the
operation shows a failure of a particular measurement or reduced performance of the
measurement below a configured threshold, the router stops using either the static route
or PBR logic. This combination of features provides a means to control when the static
and PBR paths are used and when they are ignored.
www.CareerCert.info
Chapter 11: Policy-Based Routing and IP Service Level Agreement 373
This section begins with discussion of IP SLA as an end to itself. Following that, the topic
of SLA object tracking is added, along with how to configure static routes and PBR to
track IP SLA operations so IOS knows when to use, and when to ignore, these routes.
Understanding IP SLA Concepts
IP SLA uses the concept of an operation. Each operation defines a type of packet that
the router will generate, the destination and source address, and other characteristics of
the packet. The configuration includes settings about the time-of-day when the router
should be sending the packets in a particular operation, the types of statistics that should
be gathered, and how often the router should send the packets. Also, you can configure a
router with multiple operations of different types.
For example, a single IP SLA operation could define the following:
■ Use ICMP echo packets.
■ Measure the end-to-end round trip response time (ICMP echo).
■ Send the packets every 5 minutes, all day long.
Note: For those of you who have been around IOS for a while, IP SLA may sound familiar.
IP SLA has origins in earlier IOS features, including the Response Time Reporter
(RTR) feature. The RTR feature uses the rtr command and uses the term probe to refer to
what IP SLA refers to as an operation.
All the SLA operations rely on the router sending packets and some other device sending
packets back. Figure 11-3 shows the general idea and provides a good backdrop to discuss
some related issues.
Key
Topic
SLA Operation
R2
R3
R1
S1
SLA Responder
RTP
RTP
ICMP echo request
ICMP echo reply
1
2
3
4 SLA Operation
Normal Ser ver
(no special
services)
Figure 11-3 Sending and Receiving Packets with IP SLA
www.CareerCert.info
374 CCNP ROUTE 642-902 Official Certification Guide
An IP SLA operation can cause the router to send packets to any IP address, whether on a
router or a host. When sending to a host, as in the bottom part of the figure, the host does
not need any special software or configuration–instead, the host just acts as normal. That
means that if an SLA operation sends packets to a host, the router can only use operation
types that send packets that the host understands. For instance, the router could use
ICMP echo requests, TCP connection requests, or even HTTP GET requests to a web
server, because the server should try to respond to these requests.
The operation can also send packets to another router, which gives IP SLA a wider range of
possible operation types. If the operation sends packets to which the remote router would
normally respond, like ICMP echo requests, the other router needs no special configuration.
However, IP SLAsupports the concept of the IP SLAresponder, as noted in Figure
11-3 for R2. By configuring R2 as an IP SLA responder, it responds to packets that a router
would not normally respond to, giving the network engineer a way to monitor network behavior
without having to place devices around the network just to test the network.
For example, the operation could send Real-time Transport Protocol (RTP) packets–packets
that have the same content as VoIP–as shown in Figure 11-3 as Step 1. Then the IP SLA
responder function on R2 can reply back as if a voice call exists between the two routers,
as shown in Step 2 of that figure.
A wide range of IP SLA operations exist. The following list summarizes the majority of
the available operation types, just for perspective:
■ ICMP (echo, jitter)
■ RTP (VoIP)
■ TCP connection (establishes TCP connections)
■ UDP (echo, jitter)
■ DNS
■ DHCP
■ HTTP
■ FTP
Configuring and Verifying IP SLA
This book describes IP SLA configuration in enough depth to get a sense for how it can
be used to influence static routes and policy routing. To that end, this section examines
the use of an ICMP echo operation, which requires configuration only on one router, with
no IP SLA responder. The remote host, router, or other device replies to the ICMP Echo
Requests just like any other ICMP echo requests.
The general steps to configure an ICMP-based IP SLA operation are as follows:
Step 1. Create the IP SLA Operation, and assign it an integer operation number, using
Key the ip sla sla-ops-number global configuration command.
Topic
www.CareerCert.info
Chapter 11: Policy-Based Routing and IP Service Level Agreement 375
Step 2. Define the operation type and the parameters for that operation type. For
ICMP echo, you define the destination IP address or hostname, and optionally,
the source IP address or hostname, using the icmp-echo {destination-ipaddress
| destination-hostname} [source-ip {ip-address | hostname} |
source-interface interface-name] SLA operation subcommand.
Step 3. (Optional) Define a (nondefault) frequency that the operation should send the
packets, in seconds, using the frequency seconds IP SLA subcommand.
Step 4. Schedule when the SLA will run, using the ip sla schedule sla-ops-number
[life {forever | seconds}] [start-time {hh:mm[:ss] [month day | day month] |
pending | now | after hh:mm:ss}] [ageout seconds] [recurring] global command.
Example 11-4 shows the process of configuring an ICMP Echo operation on Router R1
from Figure 11-2. The purpose of the operation is to test the PBR route through R4. In this
case, the operation will be configured as shown in Figure 11-4, with the following criteria:
■ Send ICMP Echo Requests to server S1 (10.1.3.99).
■ Use source address 10.1.1.9 (R1’s F0/0 IP address).
■ Send these packets every 60 seconds.
■ Start the operation immediately, and run it forever.
■ Enable PBR for locally generated packets, matching the IP SLA operation with the
PBR configuration so that the SLA operation’s packets flow over the lower route.
Example 11-4 Configuring an ICMP Echo Operation on Router R1
R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# ip sla 11
R1(config-ip-sla)#icmp?
icmp-echo icmp-jitter
R1(config-ip-sla)# icmp-echo 10.1.3.99 source-ip 10.1.1.9
R1(config-ip-sla)# frequency 60
R1(config-ip-sla)# exit
R1(config)# ip sla schedule 11 start-time now life forever
! Changes to the PBR configuration below
R1(config)# access-list 101 permit ip host 10.1.1.9 host 10.1.3.99
R1(config)# ip local policy PC2-over-low-route
R1(config)# end
First, focus on the pure IP SLA configuration, located from the beginning of the example
up through command ip sla schedule. The configuration creates IP SLA operation 11. The
parameters on the icmp-echo command act as if you used an extended ping from the command
line, specifying both the source and destination IP address. The last command directly
related to IP SLA, the ip sla schedule command, enables the operation now, and
runs the operation until the network engineer takes some action to disable it, in some
cases by removing the operation with the no ip sla sla-ops-number command.
The last two commands in the example show a change to the earlier PBR configuration so
that the SLA operation’s packets flow over the lower route. The ip local policy PC2-overlow-
route global command tells R1 to process packets generated by R1, including the IP
SLA operation packets, using PBR. The addition of the access-list 101 command to the
configuration shown earlier in Example 11-1 makes the route map match the source and
destination address of the SLA operation. That former route map’s set command sent the
packets over the link to R4.
IP SLA supports a couple of particularly useful verification commands: show ip sla configuration
and show ip sla statistics. The first command confirms all the configuration settings
for the operation, and the second lists the current statistics for the operation. Example 11-5
shows examples of each on R1, after the configuration shown in Example 11-4.
Example 11-5 Verification of an IP SLA Operation
R1# show ip sla configuration
IP SLAs Infrastructure Engine-II
Entry number: 11
Owner:
Tag:
Type of operation to perform: echo
Target address/Source address: 10.1.3.99/10.1.1.9
www.CareerCert.info
Chapter 11: Policy-Based Routing and IP Service Level Agreement 377
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Operation timeout (milliseconds): 5000
Verify data: No
Vrf Name:
Schedule:
Operation frequency (seconds): 60 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000 (not considered if react RTT is configured)
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None
Enhanced History:
R1# show ip sla statistics 11
IPSLAs Latest Operation Statistics
IPSLA operation id: 11
Latest RTT: 8 milliseconds
Latest operation start time: *19:58:08.395 UTC Mon Sep 14 2009
Latest operation return code: OK
Number of successes: 22
Number of failures: 0
Operation time to live: Forever
The highlighted lines in the output of the show ip sla configuration command correspond
to the values explicitly configured in Example 11-4. The more interesting output
exists in the output of the show ip sla statistics 11 command, which lists the statistics
only for operation 11. In this case, 22 intervals have passed, showing 22 ICMP Echo Requests
as successful with no failures. It also lists the latest round trip time (RTT). Finally, it
lists the return code of the most recent operation (OK in this case)–a key value used by
SLA tracking.
www.CareerCert.info
378 CCNP ROUTE 642-902 Official Certification Guide
Key
Topic
SLA
Operation
Tracking
Object
Static Route PBR
Figure 11-5 Configuration Relationships for Path Control Using IP SLA
Key
Topic
Tracking SLA Operations to Influence Routing
As previously mentioned, you can configure both static routes and PBR to be used only
when an SLA operation remains successful. The configuration to achieve this logic requires
the configuration of a tracking object and cross references between the static route,
PBR, and IP SLA, as shown in Figure 11-5.
The tracking object looks at the IP SLA operation’s most recent return code to then determine
the tracking state as either “up” or “down.” Depending on the type of SLA operation,
the return code may be a simple toggle, with “OK” meaning that the last operation
worked. The tracking object would then result in an “up” state if the SLA operation resulting
in an “OK” return code. Other SLA operations that define thresholds have more possible
return codes. The tracking operation results in an “up” state if the IP SLA operation is
within the configured threshold.
One of the main reasons that IOS requires the use of this tracking object is so that the
routes do not flap. Route flapping occurs when a router adds a route to the routing table,
then quickly removes it; conditions change, so the router soon adds the route to the table
again; and so on. If a static route tracked the IP SLA object directly, the SLA object’s return
code could change each time the operation ran, causing a route flap. The tracking object
concept provides the ability to set a delay of how soon after a tracking state change
the tracking object should change state. This feature gives the engineer a tool to control
route flaps.
This section shows how to configure a tracking object for use with both a static route and
with PBR.
Configuring a Static Route to Track an IP SLA Operation
To configure a static route to track an IP SLA, you need to configure the tracking object
and then configure the static route with the track keyword. To do so, use these steps:
Step 1. Use the track object-number ip sla sla-ops-number [state | reachability]
global command.
www.CareerCert.info
Chapter 11: Policy-Based Routing and IP Service Level Agreement 379
Step 2. (Optional) Configure the delay to regulate flapping of the tracking state by
using the delay {down seconds | up seconds} command in tracking configuration
mode.
Step 3. Configure the static route with the ip route destination mask {interface |
next-hop} track object-number global command.
Example 11-6 shows the configuration of tracking object 2, using the same design shown
in Figure 11-2 and 11-4. In this case, the configuration adds a static route for subnet
10.1.234.0/24, the LAN subnet to which R2, R3, and R4 all connect. EIGRP chooses a route
over R1’s S0/0/0 as its best route, but this static route uses S0/0/1 as the outgoing interface.
Example 11-6 Configuring a Static Route with Tracking IP SLA
R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# track 2 ip sla 11 state
R1(config-track)# delay up 90 down 90
R1(config-track)# exit
R1(config)# ip route 10.1.234.0 255.255.255.0 s0/0/1 track 2
R1(config)# end
The configuration begins with the creation of the tracking object number 2. As with IP
SLA operation numbers, the number itself is unimportant, other than that the ip route
command refers to this same number with the track 2 option at the end of the command.
The tracking object’s delay settings have been made at 90 seconds.
The show track command lists the tracking object’s configuration plus many other details.
It lists the current tracking state, the time in this state, the number of state transitions, and
the other entities that track the object (in this case, a static route).
Example 11-7 shows what happens when the IP SLA operation fails, causing the static
route to be removed. The example starts with the configuration shown in Example 11-6,
along with the SLA operation 11 as configured in Example 11-4. The following list details
the current operation and what happens sequentially in the example:
Step 1. Before the text seen in Example 11-7, the current IP SLA operation already
sends packets using PBR, over R1’s link to R4, using source IP address 10.1.1.9
and destination 10.1.3.99 (server S1).
Step 2. At the beginning of the next example, because the IP SLA operation is working,
the static route is in R1’s IP routing table.
Step 3. An ACL is configured on R4 (not shown) so that the IP SLA operation fails.
Step 4. A few minutes later, R1 issues a log message stating that the tracking object
changed state from up to down.
Step 5. The example ends with several commands that confirm the change in state for
the tracking object, and confirmation that R1 now uses the EIGRP learned
route through R2.
www.CareerCert.info
380 CCNP ROUTE 642-902 Official Certification Guide
Note: This example uses the show ip route ... longer-prefixes command because this
command lists only the route for 10.1.234.0/24, which is the route that fails over in the
example.
Example 11-7 Verifying Tracking of Static Routes
! Next – Step 2 Step 2 Step 2 Step 2
R1# show ip route 10.1.234.0 255.255.255.0 longer-prefixes
! Legend omitted for brevity
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
S 10.1.234.0/24 is directly connected, Serial0/0/1
R1# show track
Track 2
IP SLA 11 state
State is Up
1 change, last change 01:24:14
Delay up 90 secs, down 90 secs
Latest operation return code: OK
Latest RTT (millisecs) 7
Tracked by:
STATIC-IP-ROUTING 0
!
! Next, Step 3 Step 3 Step 3
! Not shown – SLA Operations packets are now filtered by an ACL on R4
! Sometime later...
!
! Next – Step 4 Step 4 Step 4 Step 4
R1#
*Sep 14 22:55:43.362: %TRACKING-5-STATE: 2 ip sla 11 state Up->Down
! Final Step – Step 5 Step 5 Step 5 Step 5
R1# show track
Track 2
IP SLA 11 state
State is Down
2 changes, last change 00:00:15
Delay up 90 secs, down 90 secs
Latest operation return code: No connection
Tracked by:
STATIC-IP-ROUTING 0
R1# show ip route 10.1.234.0 255.255.255.0 longer-prefixes
! Legend omitted for brevity
www.CareerCert.info
Chapter 11: Policy-Based Routing and IP Service Level Agreement 381
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
D 10.1.234.0/24 [90/2172416] via 10.1.12.2, 00:00:25, Serial0/0/0
Configuring PBR to Track an IP SLA
To configure PBR to use object tracking, use a modified version of the set command in
the route map. For instance, the earlier PBR configuration used the following set command:
set ip next-hop 10.1.14.4
Instead, use the verify-availability keyword, as shown in this command:
set ip next-hop verify-availability 10.1.14.4 1 track 2
When the tracking object is up, PBR works as configured. When the tracking object is
down, PBR acts as if the set command does not exist. That means that the router will still
attempt to route the packet per the normal destination-based routing process.
The output of the related verification commands does not differ significantly when comparing
the configuration of tracking for static routes versus PBR. The show track command
lists “ROUTE-MAP” instead of “STATIC-IP-ROUTING,” but the details of the show
track, show ip sla statistics, and object tracking log message seen in Example 11-7, remain
the same.