Service provider customers can use IP SLA to measure and provide service level agreements; while enterprise customers can use IP SLA to verify the outsourced service level agreements, and understand network performance for both existing and new IP applications and services. IP SLA provides improvements over the traditional Layer 2 SLA to provide a broader scope to support end-to-end sophisticated and accurate application-aware performance measurements.
Various IP SLA operations provide useful measurement statistics for network assessments, verifying Quality of Service (QoS), easing the deployment of new IP applications and services, designing networks, problem analysis, and network troubleshooting.
IP SLA generates traffic in a continuous, predictable, and reliable manner to measure network performance. IP SLA performs active monitoring by generating and analyzing traffic to measure performance either between Cisco IOS devices or between a Cisco IOS device and a normal application server. IP SLA uses unique service level assurance metrics and methodology to provide highly accurate, precise service level assurance measurements.
IP SLA sends data across the network to measure performance between multiple network locations or across multiple network paths. It simulates network data and IP services, and collects network performance information in real time. The information collected includes round-trip response time, one-way latency, jitter (inter-packet delay variance), packet loss, packet sequence, voice quality scoring, network resource availability, application performance, server response time, and download time.
The statistics collected by IP SLA operations are stored in both CLI and SNMP MIBs that can be assessed using the CLI or SNMP through the Cisco Round-Trip Time Monitor (RTTMON) and SYSLOG Management Information Bases (MIBs). Network management systems such as CiscoWorks Internetwork Performance Monitor (IPM) and other 3rd party Cisco partner performance management products are able to collect the statistics data using SNMP and generate reports to justify whether a network has reached the SLAs defined for it.
IP SLA mainly uses operations for its operation. Each operation defines the packet type to be generated, the source and destination addresses, and other characteristics of the packets. The configuration includes the time-of-day when the router should generate the packets, the types of statistics that should be gathered, and how often the packets should be generated. A single router can be configured with different types of IP SLA operations.
Note: IP SLA has origins in earlier IOS, including the Response Time Reporter (RTR) feature. The RTR feature uses the term probe to refer to what IP SLA refers to as an operation.
An IP SLA operation is able to send packets to any IP address, whether it is a router or a host. When sending to a host, no special software or configuration is required on the host; indeed the IP SLA operation send operational packets only to the native services on the host, eg: ICMP echo requests, TCP connection requests, or even HTTP GET requests to a web server. The server will try to respond to these requests.
The Operation of IP SLA
An IP SLA operation can also send packets to another router that acts as an IP SLA responder, which provides a wider range of possible operation types. An IP SLA responder responds to IP SLA request packets that a router would not normally respond to, providing a way to monitor network behavior without introducing dedicated probes around the network to test the network. Ex: An IP SLA operation could send Real-time Transport Protocol (RTP) packets that have the same content as VoIP packets to an IP SLA responder. The IP SLA responder replies the packets back to the IP SLA operation as if a voice call exists between the 2 routers.
Below list the various types of IP SLA operations:
Dynamic Host Configuration Protocol (DHCP)
Data Link Switching Plus (DLSw+)
Domain Name System (DNS)
File Transfer Protocol (FTP)
Hypertext Transfer Protocol (HTTP)
ICMP Echo and ICMP Path Echo
ICMP Jitter and ICMP Path Jitter
Transmission Control Protocol (TCP) Connect
UDP Echo and UDP Jitter
VoIP gatekeeper registration delay
VoIP post-dial delay
VoIP Real-time Transport Protocol (RTP)
Below are the general steps to configure an IP SLA ICMP Echo operation:
Step 1) Create the IP SLA operation and assign it an integer operation number using the ip sla {sla-ops-num} global configuration command.
Step 2) Define the IP SLA operation type and the parameters for that operation type. For ICMP Echo, define the source (optional) and destination IP addresses or hostnames using the icmp-echo {dest-ip-addr | dest-hostname} [source-ip {src-ip-addr | src-hostname} | source-interface {intf-type intf-num}] IP SLA operation subcommand.
Step 3) (Optional) Define a (non-default) frequency that the IP SLA operation should send the packets using the frequency {seconds} IP SLA subcommand. The default frequency is 60 seconds.
Step 4) Schedule the IP SLA operation to run for a period to gather statistics using the ip sla schedule {sla-ops-num} [life {forever | seconds}] [start-time {hh:mm[:ss] [month day | day month] | pending | now | after hh:mm:ss}] [ageout seconds] [recurring] global configuration command.
Static routes and PBR can be configured to utilize the capabilities of IP SLA operations upon controlling the usages of the static and PBR paths based upon the failure or reduced performance (based on the configured threshold) of a particular measurement.
This section describes the concepts of IP SLA and along with its configuration in enough depth for influencing static routes and policy routing. Below implements an ICMP echo operation, which requires configuration only on one router, with no IP SLA responder. The remote router or host replies to the IP SLA ICMP Echo Requests just like any other ICMP Echo Requests.
IP SLA Echo Operation
Note: The configuration is enhanced so that small ping packets sent between PC1, PC2, and RT1 as well as EIGRP Hellos packets between 11.11.11.1 and 11.11.11.2 are not being policy routed.
Below shows the process of implementing an ICMP Echo operation on RT1 with the purpose to test the PBR route through the secondary path – 22.22.22.0/30. The operation is configured to:
Send ICMP Echo Requests to RT2 E0/0 – 172.16.1.1).
Use the secondary IP address of RT1 E0/0 (192.168.2.1) as the source IP address.
Send the packets every 10 seconds.
Start the operation immediately, and run it forever.
Enable local policy routing on RT1 for the locally originated IP SLA ICMP Echo operation packets to flow through the secondary path.
Configuring an IP SLA ICMP Echo operation on RT1:
RT1#conf t Enter configuration commands, one per line. End with CNTL/Z. RT1(config)#ip sla 1 RT1(config-ip-sla)#icmp-echo 172.16.1.1 source-ip 192.168.2.1 RT1(config-ip-sla-echo)#frequency 10 RT1(config-ip-sla-echo)#exit RT1(config)#ip sla schedule 1 life forever start-time now RT1(config)#ip local policy route-map RM-PBR
The parameters of the icmp-echo IP SLA subcommand acts as an extended ping from the CLI, which it specifies both the source and destination IP addresses.
The show ip sla configuration [sla-ops-num] EXEC command displays the configuration details including all the default values for all IP SLA operations or a specified IP SLA operation:
RT1#sh ip sla configuration IP SLAs Infrastructure Engine-II Entry number: 1 Owner: Tag: Type of operation to perform: icmp-echo Target address/Source address: 172.16.1.1/192.168.2.1 Operation timeout (milliseconds): 5000 Type Of Service parameters: 0x0 Vrf Name: Request size (ARR data portion): 28 Verify data: No Schedule: Operation frequency (seconds): 10 (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: RT1#
The show ip sla statistics [sla-ops-num] [details] EXEC command displays the current operational status and statistics for all IP SLA operations or a specified IP SLA operation:
RT1#sh ip sla statistics IPSLAs Latest Operation Statistics IPSLA operation id: 1 Latest RTT: 28 milliseconds Latest operation start time: *13:44:38.003 UTC Fri May 14 2010 Latest operation return code: OK Number of successes: 3 Number of failures: 0 Operation time to live: Forever RT1#The command output shows that 3 intervals have passed, 3 ICMP Echo Requests were success with no failures; the latest round-trip time, and the return code of the most recent operation – a key value used for IP SLA tracking.
IP SLA Tracking
A static or policy route can be configured in a way that it will be used only when an IP SLA operation remains successful. The configuration introduces a tracking object that is being referenced by the static route, policy route, and IP SLA operation as shown in the figure above.
The tracking object determines its tracking state as either UP or DOWN based on the most recent return code of the IP SLA operation. The IP SLA return codes vary upon different types of IP SLA operations. The return code may be an OK meaning that the last operation is successful, in which the tracking object would result in an UP state; or other return codes for other IP SLA operations that define thresholds. The tracking operation remains in an UP state as long as the result of the IP SLA operation is within the configured threshold.
Another great usage of the tracking object is to control route flapping. Route flap occurs when a router adding and removing a route in the routing table in a very frequent manner. If a static route is being tracked by an IP SLA operation, the return code of the IP SLA operation could change upon every operation and results in a route flap. A delay can be set to determine how long a tracking object must wait to change its state upon a tracking state change.
Below lists the steps to configure a static route to track an IP SLA operation:
Step 1) Create a tracking object to an IP SLA operation using the track {obj-num} ip sla {sla-ops-num} {state | reachability} global configuration command. The state and reachability keywords track the IP SLA operation return code and whether the route is reachable respectively.
Note: This command was introduced on Cisco IOS Release 12.4(20)T.
Step 2) (Optional) Configure the delay period to regulate flapping of the tracking state using the delay {down {seconds} | up {seconds}}. The down and up keywords indicate the delay periods for the notifications of a DOWN event and an UP event respectively.
Step 3) Configure the static route using the ip route {dest-network} {subnet-mask} {next-hop-addr | outgoing-intf} track {obj-num} global configuration command.
Ex: The delay down 30 up 10 tracking subcommand indicates that the clients that are tracking the object are notified after 30 seconds and 10 seconds upon the tracking state changes from UP to DOWN and from DOWN to UP respectively.
Below implements a static route that tracks a tracking object that tracking the existing IP SLA ICMP Echo operation on RT1:
RT1#conf t Enter configuration commands, one per line. End with CNTL/Z. RT1(config)#track 1 ip sla 1 state RT1(config-track)#delay down 30 up 10 RT1(config-track)#exit RT1(config)# RT1(config)#ip route 172.16.2.0 255.255.255.0 11.11.11.2 track 1 RT1(config)#end RT1#sh ip route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 2 subnets D 172.16.1.0 [90/30720] via 11.11.11.2, 00:04:24, FastEthernet0/1 S 172.16.2.0 [1/0] via 11.11.11.2 22.0.0.0/30 is subnetted, 1 subnets C 22.22.22.0 is directly connected, Serial1/0 11.0.0.0/30 is subnetted, 1 subnets C 11.11.11.0 is directly connected, FastEthernet0/1 C 192.168.1.0/24 is directly connected, FastEthernet0/0 C 192.168.2.0/24 is directly connected, FastEthernet0/0 RT1# RT1#sh track Track 1 IP SLA 1 state State is Up 1 change, last change 00:00:51 Delay up 10 secs, down 30 secs Latest operation return code: OK Latest RTT (millisecs) 60 Tracked by: STATIC-IP-ROUTING 0 RT1#
Below implements an access list on RT2 to block ICMP Echo packets which results in the IP SLA operation fails, and causes the static route to be removed on RT1. RT1 will then uses the EIGRP route to reach 172.16.2.0/24.
RT2#conf t Enter configuration commands, one per line. End with CNTL/Z. RT2(config)#access-list 111 deny icmp any any RT2(config)#access-list 111 permit ip any any RT2(config)#int s1/0 RT2(config-if)#ip access-group 111 in RT2(config-if)# ====================================================================== RT1# 14:13:53: %TRACKING-5-STATE: 1 ip sla 1 state Up->Down RT1# RT1#sh ip sla statistics IPSLAs Latest Operation Statistics IPSLA operation id: 1 Latest RTT: NoConnection/Busy/Timeout Latest operation start time: *14:13:49.927 UTC Fri May 14 2010 Latest operation return code: No connection Number of successes: 14 Number of failures: 4 Operation time to live: Forever RT1# RT1#sh track Track 1 IP SLA 1 state State is Down 2 changes, last change 00:00:07 Delay up 10 secs, down 30 secs Latest operation return code: No connection Tracked by: STATIC-IP-ROUTING 0 RT1# RT1#sh ip route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 2 subnets D 172.16.1.0 [90/30720] via 11.11.11.2, 00:06:18, FastEthernet0/1 D 172.16.2.0 [90/30720] via 11.11.11.2, 00:00:12, FastEthernet0/1 22.0.0.0/30 is subnetted, 1 subnets C 22.22.22.0 is directly connected, Serial1/0 11.0.0.0/30 is subnetted, 1 subnets C 11.11.11.0 is directly connected, FastEthernet0/1 C 192.168.1.0/24 is directly connected, FastEthernet0/0 C 192.168.2.0/24 is directly connected, FastEthernet0/0 RT1# RT1#ping 172.16.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.2.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/24/52 ms RT1#
The earlier set action in the route map used for the PBR – set ip next-hop 22.22.22.x can be modified to use object tracking to track the availability of the next hop – 22.22.22.x using the set ip next-hop verify-availability 22.22.22.x {seq-num} track 1 action.
Below shows that when the tracking object is UP, PBR works as configured. When the tracking object is DOWN, PBR acts as if the set action does not exist, and proceed to route the packets as per the normal destination-based routing process.
Note: Similar configuration should be implemented on RT2 as well to avoid asymmetric routing.
RT1#conf t Enter configuration commands, one per line. End with CNTL/Z. RT1(config)#route-map RM-PBR permit 10 RT1(config-route-map)#no set ip next-hop 22.22.22.2 RT1(config-route-map)#set ip next-hop verify-availability 22.22.22.2 1 track 1 RT1(config-route-map)#route-map RM-PBR permit 20 RT1(config-route-map)#no set ip next-hop 22.22.22.2 RT1(config-route-map)#set ip next-hop verify-availability 22.22.22.2 1 track 1 RT1(config-route-map)#end RT1# RT1#sh route route-map RM-PBR, permit, sequence 10 Match clauses: ip address (access-lists): 101 Set clauses: ip next-hop verify-availability 22.22.22.2 1 track 1 [up] Policy routing matches: 24 packets, 1536 bytes route-map RM-PBR, permit, sequence 20 Match clauses: ip address (access-lists): 102 length 1 100 Set clauses: ip next-hop verify-availability 22.22.22.2 1 track 1 [up] Policy routing matches: 0 packets, 0 bytes RT1# RT1#sh track Track 1 IP SLA 1 state State is Up 1 change, last change 00:00:47 Delay up 10 secs, down 30 secs Latest operation return code: OK Latest RTT (millisecs) 100 Tracked by: ROUTE-MAP 0 STATIC-IP-ROUTING 0 RT1# ! After applied the Block-ICMP-ACL on RT2 Serial1/0 and waited 30 seconds... 16:33:17: %TRACKING-5-STATE: 1 ip sla 1 state Up->Down RT1#sh route route-map RM-PBR, permit, sequence 10 Match clauses: ip address (access-lists): 101 Set clauses: ip next-hop verify-availability 22.22.22.2 1 track 1 [down] Policy routing matches: 26 packets, 1664 bytes route-map RM-PBR, permit, sequence 20 Match clauses: ip address (access-lists): 102 length 1 100 Set clauses: ip next-hop verify-availability 22.22.22.2 1 track 1 [down] Policy routing matches: 0 packets, 0 bytes RT1#
The IEEE Network projects Networking Projects for Final Year CSE Students has direct impact on undergraduate and graduate student education and training. Final Year Engineering Students who are software developers can structure a project around building a network firewall application Final Year Project Centers in Chennai
ReplyDeleteJavaScript Training in Chennai
JavaScript Training in Chennai