Kevin Dorrell, CCIE #20765

06 Apr 2008

NMC 14.14 SLA Jitter measurements

Filed under: IOS features — dorreke @ 14:26

Notes:

  1. You cannot clear counters on a subinterface, e.g. R1-S0/0.13.  The only way to clear the ip precedence accounting counters on S0/0.13 is to do clear counters S0/0.  Note that clear ip accounting has no effect on precedence accounting.
  2. The AK talks about 1 extra packet sent per sample: “think of this as a control-plane packet”.  Monitoring with Ethereal, I see the probe 100 packets and their responses: R5 UDP/56984 to R1 UDP/16387.  These are preceded by a single packet R5 UDP/56984 to R1 UDP/1967 which has 52 bytes of data.  This is presumably the control packet they are talking about, and primes R1 for the burst of test packets.  R1 responds to it with a single packet that has 8 bytes of data.

At the moment, I run Ethereal on an isolated laptop.  I must get it running on the main PC so that I can put Ethereal dumps into my blogs.  Too much text is indigestible.  I would need a second Ethernet card in the PC so I could monitor the lab traffic seperately and have my home network running at the same time.

The AK does not include any samples of the most interesting part of the SLA monitoring, which is the results.  Here are some results:

R5#show ip sla monitor statistics
Round trip time (RTT)   Index 3
        Latest RTT: 19 ms
Latest operation start time: 13:22:10.707 UTC Sun Apr 6 2008
Latest operation return code: OK
RTT Values
        Number Of RTT: 83
        RTT Min/Avg/Max: 13/22/379 ms
Latency one-way time milliseconds
        Number of Latency one-way Samples: 43
        Source to Destination Latency one way Min/Avg/Max: 0/16/364 ms
        Destination to Source Latency one way Min/Avg/Max: 14/14/18 ms
Jitter time milliseconds
        Number of Jitter Samples: 81
        Source to Destination Jitter Min/Avg/Max: 1/10/365 ms
        Destination to Source Jitter Min/Avg/Max: 1/1/4 ms
Packet Loss Values
        Loss Source to Destination: 17          Loss Destination to Source: 0
        Out Of Sequence: 0      Tail Drop: 0    Packet Late Arrival: 0
Voice Score Values
        Calculated Planning Impairment Factor (ICPIF): 0
        Mean Opinion Score (MOS): 0
Number of successes: 14
Number of failures: 0
Operation time to live: Forever


Round trip time (RTT)   Index 4
        Latest RTT: 22 ms
Latest operation start time: 13:22:14.188 UTC Sun Apr 6 2008
Latest operation return code: OK
RTT Values
        Number Of RTT: 83
        RTT Min/Avg/Max: 13/27/390 ms
Latency one-way time milliseconds
        Number of Latency one-way Samples: 45
        Source to Destination Latency one way Min/Avg/Max: 0/15/358 ms
        Destination to Source Latency one way Min/Avg/Max: 14/23/390 ms
Jitter time milliseconds
        Number of Jitter Samples: 81
        Source to Destination Jitter Min/Avg/Max: 1/11/358 ms
        Destination to Source Jitter Min/Avg/Max: 1/31/376 ms
Packet Loss Values
        Loss Source to Destination: 17          Loss Destination to Source: 0
        Out Of Sequence: 0      Tail Drop: 0    Packet Late Arrival: 0
Voice Score Values
        Calculated Planning Impairment Factor (ICPIF): 0
        Mean Opinion Score (MOS): 0
Number of successes: 14
Number of failures: 0
Operation time to live: Forever

 
I cannot find a way to clear down these statistcs.  I will find it eventually, but at least I cannot be tested on that in the exam!

It is interesting that I seem to have lost 17 packets on their way from source to destination.  This is confirmed by the precedence counters at R1.  I wonder why.  Think back to 14.13, the QoS, where we limited the bandwidth available for precedence 3 and 4 packets. 

R3#show policy-map in
 Serial0/0
  Service-policy output: R3-FR-out
    Class-map: 14.13.1 (match-all)
      4848 packets, 311232 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group name from-35.5
      Match: ip precedence 3  4
      Traffic Shaping
           Target/Average   Byte   Sustain   Excess    Interval  Increment
             Rate           Limit  bits/int  bits/int  (ms)      (bytes)
            32000/32000     3000   12000     12000     375       1500
        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping
        Active Depth                         Delayed   Delayed   Active
        -      0         4848      311232    0         0         no
      Service-policy : q-shaper
        Class-map: prec4 (match-all)
          2424 packets, 155616 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: ip precedence 4
          Queueing
            Output Queue: Conversation 25
            Bandwidth 16 (kbps) Max Threshold 64 (packets)
            (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0
        Class-map: prec3 (match-all)
          2424 packets, 155616 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: ip precedence 3
          Queueing
            Output Queue: Conversation 26
            Bandwidth 8 (kbps) Max Threshold 64 (packets)
            (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0
        Class-map: class-default (match-any)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: any
    Class-map: class-default (match-any)
      5636 packets, 289891 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
R3#

Strange!  That does not explain the lost packets.  It is pretty consistent too – losing 17 packets in each sample for each flow.  Pinged 1000 packets from R5 to 172.16.101.1, and did not lose a single one.  The packet probe rate during each burst is 1 packet every 20 msec.  Try slowing this down to 100 msec.  That reduces the loss on that flow to 5 packets per sample.  I wonder where they are getting lost.  Still looking.

(Subversive thought: This stuff is unlikely to be needed in the exam at this level.  Should I be concentrating rather on the exam?  If I get my digits, will it mean that I will stop labbing this sort of stuff?  That would indeed be a pity.)

 

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: