Notes:
- 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.
- 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.)
