Tag Archives: 6.4a

6.4.a Implement and troubleshoot IP SLA

  • 6.4.a [i] ICMP, UDP, Jitter, VoIP

The IP SLAs ICMP jitter operation supports the following statistical measurements:

● Jitter (source-to-destination and destination-to-source)

● Latency (source-to-destination and destination-to-source)

● Round-trip time latency

● Packet loss

● Successive packet loss

● Out-of-sequence packets (source-to-destination, destination-to-source, and round-trip)

● Late packets

IP SLAs ICMP jitter uses a two ICMP timestamp messages, an ICMP Timestamp Request (Type 13) and an ICMP Timestamp Reply (Type 14), to provide jitter, packet loss, and latency. IP SLAs ICMP jitter operations differ from IP SLAs ICMP echo operations in that ICMP echo uses ICMP Echo request and reply (ping). Devices that are fully compliant with ICMP must be able to respond to the time stamp messages without requiring an IP SLA responder at the destination.

The IP Service Level Agreements (SLAs) UDP jitter operation diagnoses network suitability for real-time traffic applications such as VoIP, video over IP, or real-time conferencing.

However, the IP SLAs UDP jitter operation does more than just monitor jitter. As the UDP jitter operation includes data returned by the IP SLAs UDP operation, the UDP jitter operation can be used as a multipurpose data gathering operation . The packets that IP SLAs generate carry packet-sending and receiving sequence information, and sending and receiving time stamps from the source and the operational target. Based on this information, UDP jitter operations are capable of measuring the following:

● Per-direction jitter (source to destination and destination to source)

● Per-direction packet loss

● Per-direction delay (one-way delay)

● Round-trip delay (average round-trip time)

As paths for sending and receiving data may be different (asymmetric), the per-direction data allows you to more readily identify where congestion or other problems are occurring in the network. IP SLA responder, on a target device, is not required for any probes.

The UDP jitter operation functions by generating synthetic (simulated) UDP traffic. Asymmetric probes support custom-defined packet sizes per direction with which different packet sizes can be sent in request packets (from the source device to the destination device) and in response packets (from the destination device to the source device).

The IP SLAs operations function by generating synthetic (simulated) network traffic. A single IP SLAs operation (for example, IP SLAs operation 10) repeats at a given frequency for the lifetime of the operation. IP SLA requires schedule to be configured before it can be functional and out of default pending state.

Adam, Paul (2014-07-12). All-in-One CCIE V5 Written Exam Guide (Kindle Locations 6092-6102).  . Kindle Edition.

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipsla/configuration/15-mt/sla-15-mt-book/sla_icmp_jitter.html

 

 

6.4.a Implement and troubleshoot IP SLA

ip sla monitor using nbar and wireshark…

first the simple network (the asa is for another project, this is about ip sla, 6.4a for the ccie written)…

ip_sla_w_asa

prove connectivity…

R1#ping 100.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/35/56 ms

ciscoasa(config)# sh xlate
1 in use, 2 most used
Flags: D – DNS, i – dynamic, r – portmap, s – static, I – identity, T – twice
ICMP PAT from inside:10.1.1.1/2 to outside:100.1.1.2/51441 flags ri idle 0:00:03 timeout 0:00:30

ciscoasa(config-cmap)# sh run policy-map | i icmp
inspect icmp

put nbar on the router interfaces:

R1(config)#int f0/0
R1(config-if)#ip nbar protocol-discovery

R2#sh ip nbar protocol-discovery protocol http

FastEthernet0/0
Input                    Output
—–                    ——
Protocol                 Packet Count             Packet Count
Byte Count               Byte Count
5min Bit Rate (bps)      5min Bit Rate (bps)
5min Max Bit Rate (bps)  5min Max Bit Rate (bps)
———————— ———————— ————————
http                     0                        0

use ip sla monitor to send http traffic:

R1(config)#do sh run | b ip sla
ip sla monitor 5
type http operation get url http://100.1.1.1
ip sla monitor schedule 5 life forever start-time now

prove it’s being generated:

R1(config)#do sh ip nbar proto proto http

FastEthernet0/0
Input                    Output
—–                    ——
Protocol                 Packet Count             Packet Count
Byte Count               Byte Count
5min Bit Rate (bps)      5min Bit Rate (bps)
5min Max Bit Rate (bps)  5min Max Bit Rate (bps)
———————— ———————— ————————
http                     14                       10
4492                     624
0                        0
2000                     0

capture it with wireshark:

http_asa

very nice…

add other kinds of traffic (tip of the hat to rene at http://gns3vault.com/Labs/all/)

! ICMP Echo
ip sla monitor 1
type echo protocol ipIcmpEcho 100.1.1.1
timeout 0
frequency 5
ip sla monitor schedule 1 start-time now life forever

! DNS Request
ip sla monitor 2
type dns target-addr www.cisco.com name-server 100.1.1.1
timeout 0
frequency 9
ip sla monitor schedule 2 start-time now life forever

! G711 conversation
ip sla monitor 3
type jitter dest-ipaddr 100.1.1.1 dest-port 16384 codec g711ulaw codec-numpackets 50 codec-size 160 codec-interval 20
timeout 0
frequency 1
ip sla monitor schedule 3 start-time now life forever

! G729 conversation
ip sla monitor 4
type jitter dest-ipaddr 100.1.1.1 dest-port 16385 codec g729a codec-numpackets 50 codec-size 20 codec-interval 20
timeout 0
frequency 1
ip sla monitor schedule 4 start-time now life forever

! HTTP GET Traffic
ip sla monitor 5
type http operation get url http://100.1.1.1
frequency 60
ip sla monitor schedule 5 start-time now life forever

! TCPConnect to Telnet
ip sla monitor 6
type tcpConnect dest-ipaddr 100.1.1.1 dest-port 23 control disable
timeout 1000
frequency 2
ip sla monitor schedule 6 life forever start-time now

! TCPConnect to HTTPS
ip sla monitor 7
type tcpConnect dest-ipaddr 100.1.1.1 dest-port 443 control disable
timeout 1000
frequency 3
ip sla monitor schedule 7 life forever start-time now

! TCPConnect to FTP
ip sla monitor 8
type tcpConnect dest-ipaddr 100.1.1.1 dest-port 21 control disable
timeout 1000
frequency 1
ip sla monitor schedule 8 life forever start-time now

! TCPConnect to SSH
ip sla monitor 9
type tcpConnect dest-ipaddr 100.1.1.1 dest-port 22 control disable
timeout 1000
frequency 2
ip sla monitor schedule 9 life forever start-time now

!voip-rtp
ip sla mon 10
voip rtp 100.1.1.1 source-

6.4.a Implement and troubleshoot IP SLA

i turned on ip sla for icmp, http and telnet:

r1(config)#do sh run | b sla
ip sla monitor 1
type echo protocol ipIcmpEcho 192.168.23.3
request-data-size 1500
timeout 3
frequency 2
ip sla monitor schedule 1 life forever start-time now
ip sla monitor 3
type http operation get url http://4.4.4.4
ip sla monitor schedule 3 life forever start-time now
ip sla monitor 6
type tcpConnect dest-ipaddr 4.4.4.4 dest-port 23 source-port 35846 control disable
timeout 0
frequency 5
ip sla monitor schedule 6 life forever start-time now

to monitor the activity i turned nbar on the incoming ethernet port (the destination port for both telnet and http is the loopback)

r3#sh run int f0/0
Building configuration…

Current configuration : 125 bytes
!
interface FastEthernet0/0
ip address 192.168.23.3 255.255.255.0
 ip nbar protocol-discovery
duplex auto
speed auto

to see the nbar ouput:

r3#sh ip nbar protocol-disco | i telnet|icmp|http
icmp                     3480                     1
http                     290                      175
telnet                   640                      160
secure-http              0                        0
secure-telnet            0                        0
r3#sh ip nbar protocol-disco | i telnet|icmp|http
icmp                     3516                     1
http                     290                      175
telnet                   656                      164
secure-http              0                        0
secure-telnet            0                        0
r3#sh ip nbar protocol-disco | i telnet|icmp|http
icmp                     3680                     1
http                     300                      182
telnet                   724                      181
secure-http              0                        0
secure-telnet            0                        0

this is very exciting…

nbar_byte_ct

from: http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfnbar_ps1835_TSD_Products_Configuration_Guide_Chapter.html

Monitoring and Maintaining NBAR

NBAR can determine which protocols and applications are currently running on a network. NBAR includes the Protocol Discovery feature that provides an easy way of discovering application protocols operating on an interface so that appropriate QoS policies can be developed and applied. With Protocol Discovery, you can discover any protocol traffic supported by NBAR and obtain statistics associated with that protocol.

 

6.4.a Implement and troubleshoot IP SLA

ip sla can be used as a traffic generator… there are others like jperf that can be incorporated into gns3… i’ve given it some thought here and i agree with rene over at gns3vault that if you can build the traffic into the environment with this thing, then you’ll probably be better off… it’s been a while since i used it, but it’s a good idea… nothing was ever worth anything that was free…

http://gns3vault.com/Network-Services/ip-service-level-agreement-sla.html

here is the link to his command set:

http://gns3vault.com/Blog/gns3-ip-sla-traffic-generator.html

the first thing is to test the generator… icmp will be a simple beginning…

r1(config)#do sh run | b sla
ip sla monitor 1
type echo protocol ipIcmpEcho 4.4.4.4
frequency 5
ip sla monitor schedule 1 life forever start-time now

good…  debug icmp on the target…

r4(config)#
*Mar  1 00:17:06.819: ICMP: echo reply sent, src 4.4.4.4, dst 192.168.12.1
r4(config)#
*Mar  1 00:17:11.811: ICMP: echo reply sent, src 4.4.4.4, dst 192.168.12.1
r4(config)#
*Mar  1 00:17:16.823: ICMP: echo reply sent, src 4.4.4.4, dst 192.168.12.1
r4(config)#
*Mar  1 00:17:21.823: ICMP: echo reply sent, src 4.4.4.4, dst 192.168.12.1

increase the freq to 1 sec:

r1(config)#ip sla monitor 1
Entry already running and cannot be modified
(only can delete (no) and start over)
(check to see if the probe has finished exiting)

it would be nice if you didn’t have to rebuild it to change the freq… makes sense though…

r1(config)#do sh run | b sla
ip sla monitor 1
type echo protocol ipIcmpEcho 4.4.4.4
timeout 1
frequency 1
ip sla monitor schedule 1 life forever start-time now

r4(config)#
*Mar  1 00:25:19: ICMP: echo reply sent, src 4.4.4.4, dst 192.168.12.1
*Mar  1 00:25:20: ICMP: echo reply sent, src 4.4.4.4, dst 192.168.12.1
r4(config)#
*Mar  1 00:25:21: ICMP: echo reply sent, src 4.4.4.4, dst 192.168.12.1
*Mar  1 00:25:22: ICMP: echo reply sent, src 4.4.4.4, dst 192.168.12.1
r4(config)#
*Mar  1 00:25:23: ICMP: echo reply sent, src 4.4.4.4, dst 192.168.12.1

looks like i have a new friend…