IP SLA responder QoS ToS value

Hi,
I have a question regarding the SLA setup.
We have the next scenario.
A router is configured with the SLA measurments. This router is located to a Central site of a customer and is used
only for the SLA measurments (Shadow router).
The SLA measurments configuration is based on icmp packets with a specific TOS value in order to measure the
Roundtrip delay to the different classes of the network.
Sample configuration
config)#rip sla 2
(config-ip-sla)#ticmp-echo 10.10.80.1
(config-ip-sla-echo)#request-data-size 180
(config-ip-sla-echo)#tos 160
(config)#ip sla schedule 2 start now
I have the next question:
The icmp packet with the a TOS value (e.g.TOS 160 or IPprec 101) has been generated from the Shadow router and
has as destination IP a remote site (CE). The time that this icmp echo packet reaches the remote site then does it responce
with an icmp echo reply which has the same TOS value as the icmp echo packet that recieves (i.e. 160)?
We assume that the remote site has not been configured with any qos policy for the packets with destination the SLA (shadow router).
How is possible the remote site to understand the icmp TOS field (if it is possible?) and responce with the same TOS value?
Please help me. I could not find a good answer to the web.
Thank you!

I opened a ticket for the question above to CISCO TAC .
It was proved, with captured packets (Wireshark), that the TOS value is not modified for both icmp echo request and reply packets.
The key command to remote router which responds to the icmp echo is the ip sla responder command.
I thought that the ip sla responder command can be helpful in our problem (TOS value) only to TCP & UDP packets but it also works for ICMP.

Similar Messages

IP SLA responder on Catalyst 2960S stacked

Hi
I have a pair of switches stacked:
Switch Ports Model                          SW Version          SW Image
     1    52      WS-C2960S-48FPS-L 15.0(1)SE             C2960S-UNIVERSALK9-M
*    2    52      WS-C2960S-48FPS-L 15.0(1)SE             C2960S-UNIVERSALK9-M
When I try to enable ip sla responder on the stack I get:
%SYS-3-HARIKARI: Process IP SLAs Responder top-level routine exited
I have been able to find a bug in the toolkit. Should ip sla responder be supported on the
stack as above?
Thanks
Lee Flight

I can confirm 15.0(1)SE3 still has the bug.
I just tested 15.0(2)SE3 released yesterday in a lab environment and....... (drum roll)..... no more HARIKARI . Hardware were two WS-C2960S-48FPS-L unstacked (one of them with installed stacking module though)
Haven't tried the earlier 15.0(2) (i.e. SE, SE1 and SE2) releases - maybe they work too.

Linksys Switches/Routers that support CISCO IP SLA Responder feature

Hi there, I'm looking for a Linksys Switch or Router that does support Cisco IP SLA Responder, this allows for measuring one way delay, etc.
I'd appreciate if somebody can help me identifying a Linksys device supporting this.
Thanks!
From Cisco website:
"...Cisco IOS IP SLA Responder is a Cisco IOS Software component whose functionality is to respond to Cisco IOS IP SLA request packets....Some of the newer Linksys devices also support this feature...."

Cisco sold Linksys to Belkin quite a while ago. Linksys business products are typically for the SMB market.
For the SLA feature you are asking about I have used the Cisco 1921.
Please remember to Kudo those that help you.
Linksys
Communities Technical Support

Qos DSCP value 46 gone, after enabling Remote Desktop Services on Windows 2012 R2 Standard

Hi,
After installing a clean Windows Server 2012 R2 with
all Windows updates I have setup Policy-Based QoS for tagging defined traffic,
in the test case all traffic to one specific ip address. Whireshark logging
displays the correct configured (46) dscp value so the group policy is
working fine. After installing Remote Desktop Services the Policy-Based QoS is
still in place but Wireshark results that the value is 0.
Can somebody explain why this happens and how to solve
it?
Regards, Edward

Hi Edward,
Thank you for posting in Windows Server Forum.
Did you find any related error for your case?
By default, Windows traffic has a DSCP value of 0. Network routers use the DSCP value to classify network packets and to queue them appropriately. The number of queues and their prioritization behavior needs to be designed as part of your organization's QoS
strategy. For example, your organization may choose to have five queues: latency-sensitive traffic, control traffic, business critical traffic, best effort traffic, and bulk data transfer traffic.
More information, please see:
Policy-based Quality of Service (QoS)
http://technet.microsoft.com/en-us/library/dd919203(v=ws.10).aspx
Hope it helps!
Thanks.
Dharmesh Solanki
TechNet Community Support
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact [email protected]

URGENT! Setting QoS DSCP value on switches

Hi,
I desperately need replies to my problem below.
I tried to set DSCP values to 2 applications, video and video conference, on cisco 3560 and cisco 2950 swtiches based on the source ip address of the servers.
So on the switches, I created an access-list to identify the servers' ip addresses.
Then I use "class-map match-any video" followed by "match access-group" for the access-list.
Then I use "policy-map policy1", then "class video" then "set dscp ef".
Finally I apply the policy to the INPUTS of all ports "service-policy input policy1"
But when I use a sniffer to sniff the ports, I see that the DSCP value is not "EF", instead it is "0x20, class 4".
Why is this so?
Where have I done wrongly?
Finally, on routers, where do I apply QOS policy? On input ports or output ports of routers?
I urgently need help.
Thank you.
Regards,
Rachel

Rachel,
Without seeing what you have in place so far, I'll see if I can answer some of those questions. If the switch connects to a router, then the outbound (egress) interface would in fact be that interface on the switch that connects to a router. Best practices dictate that the classification and marking should be done on the inbound (ingress) interface which connects the switch to the network where the host resides.
If you wanted to implement an end-to-end QoS solution, then you should configure QoS on every interface between the source and destination. This is because even FastE/GigE ports can become congested due to worm outbreak or DOS attack. But if all you want to do right now is guarantee bandwidth to the video traffic across the WAN, that can be accomplished by a) classifying and marking the video traffic as close to the source as possible, and b) configuring queuing/scheduling on the outbound WAN interface based on those markings.
Once the switch has marked the traffic with a DSCP value per (a), that DSCP value should remain intact until it reaches the WAN router per (b), and all the way until it reaches its destination. That is, unless there is a device somewhere in between that is remarking traffic. If the switch you reference is not directly connected to the router you reference, there could be another switch or router in between marking everything back to DSCP 0, meaning that all traffic is untrusted.
I don't have a 2950 here with me, but without checking syntax this is basically what you should have, if you just want to mark video traffic EF and then guarantee bandwidth on the wan:
2950:
access-list permit
class-map match-any VIDEO
match access-group
policy-map POLICY1
class VIDEO
set ip dscp 46 !
interface
service-policy input POLICY1
Router:
class-map match-any EF_VIDEO
match ip dscp 46
policy-map VIDEO_OUT
class EF_VIDEO
priority 1600
interface
service-policy output VIDEO_OUT
If you are sniffing traffic on that switch to ensure that video traffic is being marked, make sure that you are sniffing the outbound interface toward the router, not the inbound interface from the host. That will ensure that your sniffer trace picks up the traffic after it has been marked DSCP 46.
Just in case this post is related to your post where you want to lock the router WAN interface so that the 1.6 megs of video gets through but other traffic is dropped when the video takes the full 1.6 megs of bandwidth...
QoS queuing/scheduling only kicks in when the interface experiences congestion. If there is no congestion on the interface, traffic will still be marked and policed per the service policy, but not queued/scheduled - it will just fly right through the interface with the new markings. The only way to force such congestion at 1.6 megs is to use traffic shaping. You would need to shape the entire interface down to 1.6 megs, and THEN apply the priority bandwidth. This can be accomplished with a hierarchical policy-map as follows:
Router:
class-map match-any EF_VIDEO
match ip dscp 46
policy-map VIDEO_OUT
class EF_VIDEO
priority 1600
policy-map SHAPE_OUT
class class-default
shape average 1600000
service-policy VIDEO_OUT
interface
service-policy output SHAPE_OUT
I really hope I am helping you out here, please let me know how this works out. Good luck!
Best Regards
Robert

Direct traffic onto an LSP based on packets ToS value

Hello...
I am trying to push traffic onto an LSP thats mutiple paths created as below.
interface Tunnel3080
ip unnumbered Loopback0
tunnel destination 10.253.253.136
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng path-option 11 explicit name CTel-C32-CGx-CSnf-Cwil
tunnel mpls traffic-eng path-option 12 explicit name CTel-CGlb-C1275-CMar-CWil
tunnel mpls traffic-eng path-option protect 11 explicit name CTel-CGlb-C1275-CMar-CWil
ip explicit-path name CTel-CGlb-C1275-CMar-CWil enable
next-address 10.254.0.241
next-address 10.254.0.242
next-address 10.254.0.2
next-address 10.254.1.82
next-address 10.254.13.1
ip explicit-path name CTel-C32-CGx-CSnf-Cwil enable
next-address 10.254.0.242
next-address 10.254.0.241
next-address 10.254.0.2
next-address 10.254.1.82
next-address 10.254.13.1
Traffic is coming in from an interface vlan 503; and is going to lets say 10.11.1.2.
I've an ACL as below to catch the traffic into an ACL.
ip access-list extended TOS9TrafficTo10-11-1
   10 permit ip 10.32.21.2 10.11.1.2 tos 9
I tried with below to direct the traffic onto an above tunnel LSP.
route-map BO_LA permit 10
match ip address TOS9TrafficTo10-11-1
set interface Tunnel3080
and then applied the map to the interface as below...
interface vlan 503
ip policy route-map BO_LA
Its not working..   and need some assistance.. I know route maps are not the solution here as they're used for routes and not the actual traffic, I believe. Is there any other solution.
-Tarkesh

Tarkesh,
This should actually work because a route-map can also be used for policy-based routing and not just for routing information manipulation. I am in fact surprised that your configuration has no effect. The first thing coming to my mind here: is the interface Vlan503 the incoming interface for this traffic you want to send via specific MPLS TE tunnels? Is the traffic actually routed, i.e. passing through the Vlan503, or is it simply switched within VLAN 503?
Also, how do you know your configuration has no effect?
There is an option of class-based tunnel selection for ingress traffic, however, that feature is supported only on selected platforms. You can read (much) more here:
http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_te_tun_select.html

Ip SLA RTP based VOIP Operation - To find out MOS value

Hi All,
I am new to VOIP. We are trying to find out the MOS value in our VOIP network. For that we thought of using IP SLA RTP Based VOIP operation to get the MOS values. http://www.cisco.com/en/US/docs/ios/12_4t/12_4t4/htrtpvip.html
I ve used 3825 with NM HDV module with 3 DSP as SLA originator and AS 5400 XM as SLA responder.
But i'm not getting the MOS values,
show ip sla statistics shows that the operation failed due to Format Failure.
I ve attached the config of my 3825. Kindly go through it and advise if any changes to be done.
In AS 5400 XM there is no special config related to this. I ve enabled only " IP SLA RESPONDER"
Error message:
LAB-3825-R6# sh ip sla stat
Round Trip Time (RTT) for Index 1
Type of operation: rtp
Latest operation start time: *05:04:58.707 UTC Wed May 14 2008
Latest operation return code: Format failure
Latest RTT (milliseconds): 0
Source to Destination Path Measurements:
Interarrival Jitter: 0
Packets Sent: 0
Packets Lost: 0
Estimated R-factor: 0 MOS-CQ: 0.00
Destination to Source Path Measurements:
Interarrival Jitter: 0
Packets Sent: 0
Packets Lost: 0
Estimated R-factor: 0 MOS-CQ: 0.00
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never
LAB-3825-R6# sh ip sla stat aggre
Round Trip Time (RTT) for Index 1
Type of operation: rtp
Start Time Index: *05:06:21.019 UTC Wed May 14 2008
Number of successful operations: 0
Number of operations over threshold: 0
Number of failed operations due to a Timeout: 0
Number of failed operations due to a No Connection: 1
Number of failed operations due to an Internal Error: 5
Number of failed operations due to a Sequence Error: 0
RTT (avg/min/max): 0/0/0 ms
Source to Destination Path Measurements:
Interarrival Jitter (avg/min/max): 0/0/0
Packets Sent (avg/min/max): 0/0/0
Packets Lost (avg/min/max): 0/0/0
Estimated R-factor (avg/min/max): 0/0/0
MOS-CQ (avg/min/max): 0.00/0.00/0.00
Destination to Source Path Measurements:
Interarrival Jitter (avg/min/max): 0/0/0
Packets Sent (avg/min/max): 0/0/0
Packets Lost (avg/min/max): 0/0/0
Estimated R-factor (avg/min/max): 0/0/0
MOS-CQ (avg/min/max): 0.00/0.00/0.00
Any help is greatly appreciated.
thanks in advance.

Hi,
AS 5400 cannot be used even as SLA responder for RTP probe. Thats the reason i got the Format Failure error. We can view the type of SLA Probes the router supports by issuing the following command:
sh ip sla application.
for eg below is what i ve taken from AS 5400
sh ip sla application
IP Service Level Agreements
Version: Round Trip Time MIB 2.2.0, Infrastructure Engine-II
Time of last change in whole IP SLAs: 10:48:00.737 IST Tue May 20 2008
Estimated system max number of entries: 49625
Estimated number of configurable operations: 49608
Number of Entries configured : 17
Number of active Entries : 17
Number of pending Entries : 0
Number of inactive Entries : 0
Supported Operation Types
Type of Operation to Perform: dhcp
Type of Operation to Perform: dlsw
Type of Operation to Perform: dns
Type of Operation to Perform: echo
Type of Operation to Perform: frameRelay
Type of Operation to Perform: ftp
Type of Operation to Perform: http
Type of Operation to Perform: icmpJitter
Type of Operation to Perform: jitter
Type of Operation to Perform: pathEcho
Type of Operation to Perform: pathJitter
Type of Operation to Perform: tcpConnect
Type of Operation to Perform: udpEcho
Type of Operation to Perform: voip
IP SLAs low memory water mark: 68416281
chnmgw1#
Hope this will help others looking for RTP based VOIP operation..

ACE module - Qos - set ip tos #

All,
Trying to mark traffic to/from L4 rules in the ACE.
Documentation (like always) says it's really easy. Mark traffic by using the "set ip tos <value>" command in Policy/Class configuration. Ok, so I do this, set ip tos 24.
Enable qos globally on the 6500 host, but don't see the traffic being marked.
sh mls qos says that packets are being modified by module 5 (ACE)
But I never see the tos value in any of my captures either via netflow from the host 6500, or at the firewall one hop away.
sh mls qos:
QoS is enabled globally
Policy marking depends on port_trust
QoS ip packet dscp rewrite enabled globally
Input mode for GRE Tunnel is Pipe mode
Input mode for MPLS is Pipe mode
QoS Trust state is CoS on the following interface:
Te3/1
QoS Trust state is DSCP on the following interface:
Gi2/3
Vlan or Portchannel(Multi-Earl) policies supported: Yes
Egress policies supported: Yes
----- Module [5] -----
QoS global counters:
    Total packets: 207147888661
    IP shortcut packets: 0
    Packets dropped by policing: 0
    IP packets with TOS changed by policing: 2663386
    IP packets with COS changed by policing: 4889352
    Non-IP packets with COS changed by policing: 0
    MPLS packets with EXP changed by policing: 0
Can someone explain to me what I've got wrong here? Is the ACE simply marking traffic destined for the servers behind it and not the return traffic? Am I missunderstanding something?

Well... hopefully someone knows how to classify traffic coming from the ACE.
I've given up on using the ACE to mark traffic as I'm fairly certain it won't do it. At least not the way I want.
However, now I've taken to marking ingress on the rserver switch ports... which has resulted in a partially sucessful solution. Problem is, "partially" successful.
You'll have a bunch of little conversations like this with no tos value full of push-acks:
10:29:53.527526 207.161.222.68.2828 > 205.200.114.228.http: P 2954:3455(501) ack 203152 win 65535 (DF)
10:29:53.527698 205.200.114.228.http > 207.161.222.68.2828: . ack 3455 win 32267
10:29:53.555271 207.161.222.68.2828 > 205.200.114.228.http: P 3455:3686(231) ack 203152 win 65535 (DF)
10:29:53.562676 205.200.114.228.http > 207.161.222.68.2828: P 203152:203784(632) ack 3686 win 32768
10:29:53.674758 207.161.222.68.2828 > 205.200.114.228.http: P 3686:4036(350) ack 203784 win 64903 (DF)
10:29:53.690853 205.200.114.228.http > 207.161.222.68.2828: P 203784:205244(1460) ack 4036 win 32768
10:29:53.690863 205.200.114.228.http > 207.161.222.68.2828: P 205244:206704(1460) ack 4036 win 32768
10:29:53.690871 205.200.114.228.http > 207.161.222.68.2828: P 206704:208164(1460) ack 4036 win 32768
10:29:53.690879 205.200.114.228.http > 207.161.222.68.2828: P 208164:209624(1460) ack 4036 win 32768
10:29:53.690887 205.200.114.228.http > 207.161.222.68.2828: P 209624:211084(1460) ack 4036 win 32768
10:29:53.690895 205.200.114.228.http > 207.161.222.68.2828: P 211084:212544(1460) ack 4036 win 32768
But then you'll see another conversation pop up with the correct markings
10:31:53.845287 205.200.114.228.http > 207.161.222.68.2828: . 32753:34213(1460) ack 1082 win 62808 (DF) [tos 0x48]
10:31:53.845298 205.200.114.228.http > 207.161.222.68.2828: . 34213:35673(1460) ack 1082 win 62808 (DF) [tos 0x48]
10:31:53.845306 205.200.114.228.http > 207.161.222.68.2828: . 35673:37133(1460) ack 1082 win 62808 (DF) [tos 0x48]
10:31:53.845313 205.200.114.228.http > 207.161.222.68.2828: . 37133:38593(1460) ack 1082 win 62808 (DF) [tos 0x48]
10:31:53.845321 205.200.114.228.http > 207.161.222.68.2828: . 38593:40053(1460) ack 1082 win 62808 (DF) [tos 0x48]
10:31:53.845328 205.200.114.228.http > 207.161.222.68.2828: . 40053:41513(1460) ack 1082 win 62808 (DF) [tos 0x48]
10:31:53.845335 205.200.114.228.http > 207.161.222.68.2828: . 41513:42973(1460) ack 1082 win 62808 (DF) [tos 0x48]
10:31:53.845343 205.200.114.228.http > 207.161.222.68.2828: . 42973:44433(1460) ack 1082 win 62808 (DF) [tos 0x48]
I think what's happening, is that the conversations full of the P-acks is the load balancer communicating directly with the client (i.e. LB pretending to be the server), whereas the marked traffic is "data only" which the load balancer isn't mangling (like it might/probably is doing with the p-acks) on it's way back to the client.
I also can't modify the configuration of the "virtual ten gig" interface that the 6500 uses as a connection to the ACE module, so can't mark traffic there either. And though I still have a couple of things to try, I don't believe I can do egress marking on a trunk from the 6500 either (connection to the firewalls).
So.... PLEASE... Anyone??? Ideas???

IP SLA Statistics Reliable?

Hi,
I have 2 routers configured with IP SLA udp jitter monitoring both as source and destination. They are connected over a private fiber link. But the statistics has never been of any similiarity. One constantly shows a large number of packet loss, while the other shows little. Can one IP SLA operation send that large number of packets? Can someone explain this please?
Thanks in advance.
3845 is configured as:
ip sla responder
ip sla 1
udp-jitter 192.168.176.50 17000 codec g729a
tos 184
ip sla schedule 1 life forever start-time now
1841 is configured as:
ip sla responder
ip sla 1
udp-jitter 192.168.176.51 17000 codec g729a
tos 184
ip sla schedule 1 life forever start-time now
==========================================
on 3845:
sh ip sla stati 1
Round Trip Time (RTT) for       Index 1
        Latest RTT: 4 milliseconds
Latest operation start time: 13:33:54.880 NZDT Tue Sep 28 2010
Latest operation return code: OK
RTT Values:
        Number Of RTT: 999              RTT Min/Avg/Max: 3/4/37 milliseconds
Latency one-way time:
        Number of Latency one-way Samples: 999
        Source to Destination Latency one way Min/Avg/Max: 3/3/36 milliseconds
        Destination to Source Latency one way Min/Avg/Max: 1/0/2 milliseconds
Jitter Time:
        Number of Jitter Samples: 997
        Source to Destination Jitter Min/Avg/Max: 1/1/32 milliseconds
        Destination to Source Jitter Min/Avg/Max: 1/1/2 milliseconds
Packet Loss Values:
        Loss Source to Destination: 1           Loss Destination to Source: 0
        Out Of Sequence: 0      Tail Drop: 0    Packet Late Arrival: 0
Voice Score Values:
        Calculated Planning Impairment Factor (ICPIF): 11
MOS score: 4.06
Number of successes: 59
Number of failures: 0
Operation time to live: Forever
On 1841:
sh ip sla stati 1
IPSLAs Latest Operation Statistics
IPSLA operation id: 1
        Latest RTT: 4 milliseconds
Latest operation start time: 13:34:16.498 NZDT Tue Sep 28 2010
Latest operation return code: Over threshold
RTT Values:
        Number Of RTT: 999              RTT Min/Avg/Max: 3/4/7 milliseconds
Latency one-way time:
        Number of Latency one-way Samples: 510
        Source to Destination Latency one way Min/Avg/Max: 1/1/2 milliseconds
        Destination to Source Latency one way Min/Avg/Max: 3/3/6 milliseconds
Jitter Time:
        Number of SD Jitter Samples: 509
        Number of DS Jitter Samples: 508
        Source to Destination Jitter Min/Avg/Max: 0/122189/62193664 milliseconds
        Destination to Source Jitter Min/Avg/Max: 0/1/3 milliseconds
Packet Loss Values:
        Loss Source to Destination: 4294966376          Loss Destination to Source: 716
        Out Of Sequence: 233    Tail Drop: 4294966836
        Packet Late Arrival: 0 Packet Skipped: 0
Voice Score Values:
        Calculated Planning Impairment Factor (ICPIF): 11
MOS score: 4.06
Number of successes: 55
Number of failures: 0
Operation time to live: Forever

Looks like 2 different IOS version judging by the output differences, but output should be accurate.
Here is the white papaer for udp jitter:
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6602/prod_white_paper0900aecd804fb392.pdf
Looks like the 1841 is reporting a lot more drops to be sure.
However the MOS score and impairment factors are the same for both directions.
I would try clearing the counters and see if the drops reappear, if not, possibly some transient issue
led to this and the results are cumulitive.
Command refernce for this output is here:
http://www.cisco.com/en/US/partner/docs/ios/ipsla/command/reference/sla_04.html#wp1074642
Hope this helps.

IP SLA stats - one-way latency / MOS score 4.34 not updating

I'm trying to use Cisco IP SLA to bench mark voice traffic peformance before and after I apply QoS to the network.
* I've setup IP SLA in both directions over a DSL connection between a 7600, and an 1801
* I've setup IP SLA in both directions over an Ethernet WAN link between a 7200 and another 7200
ip sla 1
udp-jitter 10.101.1.1 32770 source-ip 10.101.2.1 source-port 32770 codec g711alaw
frequency 30
ip sla schedule 1 life forever start-time now
ip sla responder
I have a problem in that I'm not getting any meaningful data from the IP SLA statistics for Voice Score Values:, or any data for Latency one-way time: for any of my tests(x 4).
After a day of testing it seems the MOS score never changes from 4.34, and the ICPIF never changes from 1
Is there something wrong with my config? Is this working properly or could this be a bug?
ADSL-R1#show ip sla statistics 1 details
Round Trip Time (RTT) for       Index 1
        Latest RTT: 48 milliseconds
Latest operation start time: *09:27:48.435 UTC Thu Jul 5 2012
Latest operation return code: OK
Over thresholds occurred: FALSE
RTT Values:
        Number Of RTT: 999              RTT Min/Avg/Max: 45/48/89 milliseconds
Latency one-way time:
        Number of Latency one-way Samples: 0
        Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds
        Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds
        Source to Destination Latency one way Sum/Sum2: 0/0
        Destination to Source Latency one way Sum/Sum2: 0/0
Jitter Time:
        Number of Jitter Samples: 997
        Source to Destination Jitter Min/Avg/Max: 1/2/26 milliseconds
        Destination to Source Jitter Min/Avg/Max: 1/1/18 milliseconds
        Source to destination positive jitter Min/Avg/Max: 1/2/26 milliseconds
        Source to destination positive jitter Number/Sum/Sum2: 348/793/4295
        Source to destination negative jitter Min/Avg/Max: 1/2/16 milliseconds
        Source to destination negative jitter Number/Sum/Sum2: 346/802/3742
        Destination to Source positive jitter Min/Avg/Max: 1/1/18 milliseconds
        Destination to Source positive jitter Number/Sum/Sum2: 330/611/2051
        Destination to Source negative jitter Min/Avg/Max: 1/1/18 milliseconds
        Destination to Source negative jitter Number/Sum/Sum2: 318/606/1992
        Interarrival jitterout: 0       Interarrival jitterin: 0
Packet Loss Values:
        Loss Source to Destination: 0           Loss Destination to Source: 1
        Out Of Sequence: 0      Tail Drop: 0    Packet Late Arrival: 0
Voice Score Values:
        Calculated Planning Impairment Factor (ICPIF): 1
MOS score: 4.34
Number of successes: 72
Number of failures: 0
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never
7200-R2#show ip sla statistics details
Round Trip Time (RTT) for       Index 1
Type of operation: jitter
        Latest RTT: 6 ms
Latest operation start time: 08:08:31.349 UTC Thu Jul 5 2012
Latest operation return code: OK
RTT Values
        Number Of RTT: 1000
        RTT Min/Avg/Max: 2/6/199 ms
Latency one-way time milliseconds
        Number of Latency one-way Samples: 0
        Source to Destination Latency one way Min/Avg/Max: 0/0/0 ms
        Destination to Source Latency one way Min/Avg/Max: 0/0/0 ms
        Source to Destination Latency one way Sum/Sum2: 0/0
        Destination to Source Latency one way Sum/Sum2: 0/0
Jitter time milliseconds
        Number of SD Jitter Samples: 999
        Number of DS Jitter Samples: 999
        Source to Destination Jitter Min/Avg/Max: 0/2/13 ms
        Destination to Source Jitter Min/Avg/Max: 0/1/195 ms
        Source to destination positive jitter Min/Avg/Max: 1/1/13 ms
        Source to destination positive jitter Number/Sum/Sum2: 342/638/2142
        Source to destination negative jitter Min/Avg/Max: 1/1/11 ms
        Source to destination negative jitter Number/Sum/Sum2: 335/638/1886
        Destination to Source positive jitter Min/Avg/Max: 1/2/195 ms
        Destination to Source positive jitter Number/Sum/Sum2: 198/408/38510
        Destination to Source negative jitter Min/Avg/Max: 1/2/128 ms
        Destination to Source negative jitter Number/Sum/Sum2: 203/408/20720
        Interarrival jitterout: 0       Interarrival jitterin: 0
        Over thresholds occurred: FALSE
Packet Loss Values
        Loss Source to Destination: 0           Loss Destination to Source: 0
        Out Of Sequence: 0      Tail Drop: 0    Packet Late Arrival: 0
        Packet Skipped: 0
Voice Score Values
        Calculated Planning Impairment Factor (ICPIF): 1
MOS score: 4.34
Number of successes: 19
Number of failures: 0
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: 15:59:31.345 UTC Wed Jul 4 2012

Update (RESOVLED)
The MOS and ICPIF scores do change. I saturated the WAN link with FTP down/upload traffic inducing packet loss,increased jitter and delay. The scores degraded accordingling show ip sla statistics 10 details
R#show ip sla statistics 10
Round Trip Time (RTT) for       Index 10
Type of operation: jitter
        Latest RTT: 292 ms
Latest operation start time: 19:07:12.358 UTC Tue Jul 17 2012
Latest operation return code: OK
RTT Values
        Number Of RTT: 979
        RTT Min/Avg/Max: 58/292/487 ms
Latency one-way time milliseconds
        Number of Latency one-way Samples: 1
        Source to Destination Latency one way Min/Avg/Max: 1/1/1 ms
        Destination to Source Latency one way Min/Avg/Max: 112/112/112 ms
Jitter time milliseconds
        Number of SD Jitter Samples: 958
        Number of DS Jitter Samples: 958
        Source to Destination Jitter Min/Avg/Max: 0/1/6 ms
        Destination to Source Jitter Min/Avg/Max: 0/11/151 ms
Packet Loss Values
        Loss Source to Destination: 0           Loss Destination to Source: 21
        Out Of Sequence: 0      Tail Drop: 0
        Packet Late Arrival: 0 Packet Skipped: 0
Voice Score Values
        Calculated Planning Impairment Factor (ICPIF): 10
MOS score: 4.09
Number of successes: 32
Number of failures: 0
Operation time to live: Forever
        Source to Destination Latency one way Sum/Sum2: 9591/94681
        Destination to Source Latency one way Sum/Sum2: 346227/125286895
Jitter time milliseconds
        Number of SD Jitter Samples: 999
        Number of DS Jitter Samples: 999
        Source to Destination Jitter Min/Avg/Max: 0/2/11 ms
        Destination to Source Jitter Min/Avg/Max: 0/10/48 ms
        Source to destination positive jitter Min/Avg/Max: 1/2/11 ms
        Source to destination positive jitter Number/Sum/Sum2: 231/513/2789
        Source to destination negative jitter Min/Avg/Max: 1/2/10 ms
        Source to destination negative jitter Number/Sum/Sum2: 232/512/2724
        Destination to Source positive jitter Min/Avg/Max: 1/15/48 ms
        Destination to Source positive jitter Number/Sum/Sum2: 305/4762/93106
        Destination to Source negative jitter Min/Avg/Max: 1/6/42 ms
        Destination to Source negative jitter Number/Sum/Sum2: 682/4717/43395
        Interarrival jitterout: 0       Interarrival jitterin: 0
        Over thresholds occurred: FALSE
Packet Loss Values
        Loss Source to Destination: 0           Loss Destination to Source: 0
        Out Of Sequence: 0      Tail Drop: 0    Packet Late Arrival: 0
        Packet Skipped: 0
Voice Score Values
        Calculated Planning Impairment Factor (ICPIF): 5
MOS score: 4.24
Number of successes: 43
Number of failures: 0
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: 17:51:41.945 BST Fri Jul 20 2012

ToS Preservation with egress remarking on inner packet

Hi, I am using DMVPN/IPSEC/VRFs. On the egress of the DMVPN/VRF tunnel interfaces, I have applied a Service Policy to remark traffic. Hence the remarking occurs on the inner packet header.
Assuming qos-preclassify is NOT enabled. Does anyone know how 12.4T IOS code should operate (options)
1. Copy the "remarked" TOS value to the outer headers as part of the TOS preservation feature
2. Copy the original (pre remarking) TOS value of the inner packet header as part of the TOS preservation feature
3. Egress inner packet header remarking disables TOS preservation feature.
4. Other ?
Problem Space : At remote sites, I can easily perform the QOS remarking on the router LAN ingress interface, rather than on the egress DMVPN tunnel interface. However at the head end, the DMVPN/IPSEC/VRF routers also happen to be MPLS PE devices. Hence remarking on Layer3/4 (IP/Ports) criteria on the ingress interface is not possible as we are dealing with MPLS labels. Hence why I am attempting to do this on the egress on the DMVPN tunnel/VRF interface.
thanks
George

After testing. I can confirm that 2. appears to apply.
TOS preservation operation utilises the original inner header TOS values, rather than the remarked TOS value.
Hence even if the inner header is remarked (lets say from CS1 to AF11)on egress, the outer IPSEC header will still have the original TOS settings ie. CS1.
This aligns with the QoS Order of Operation.
http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080160fc1.shtml
which states -
"On the outbound path, common classification happens before any QoS features are applied. A result of this approach is that any QoS features applied on the outbound policy act upon the original priority value. If you need to take actions based on a remarked value on the same router, then you must mark the packets on the incoming interface and apply other QoS actions based on this new priority on the outgoing interface"
Hopefully the "qos pre-classify" feature should provide the capability to remark both the inner header and outer IPSEC header...back to testing...???
cheers
George
CCIE2980

IP SLA - not logging plus additional questions

I configured an IP SLA HTTP test and it appears to be working but it is not logging via syslog (or sh log) and it is not sending traps. My code is 124-24.T3 on a 2801 router.
1) What do I need to change to enable logging of my IP SLA results, etc.?
2) What does the "Operation time to live: 2013 sec" value mean? Typically it says "Forever" but this one has a countdown when the threshold isn't met? What is the countdown for?
config and output
logging trap debugging
snmp-server enable traps ipsla
snmp-server enable traps syslog
snmp-server host 192.168.1.125 version 2c <hidden> ipsla syslog
ip sla responder
ip sla logging traps
ip sla 80
http get http://www.google.com name-server 8.8.8.8
timeout 2000
threshold 200
owner mobiusadmin
tag Google website
frequency 120
ip sla schedule 80 start-time now
ip sla reaction-configuration 80 react timeout threshold-type immediate action-type trapOnlyip sla responder
ip sla logging traps
Thank you,

My fault. I left of the "life forever" parameter which is why the operation defaults to 3959 seconds or something like that.
As for the logging, I was hoping to capture these stats somehow via syslog but I don't think it's possbile.

QoS PreClassify Command

Hi Guys,
I hope someone can help me here. Just revising some ONT stuff before exam and realised that i do not understand when the 'qos pre-classify' command is used when implementing QoS over VPNs.
Can someone clearly expalin when exactly you use the QoS Pre-Classisfy command and when not to use it.
Forever Greatful
Stephen
PS - i'm gonna post this over in 'Certifications' also for a bit more exposure.

If the before encapsulation packets have TOS settings that you want to "analyze" after the packets have been encapsulated with a VPN packet, then you can use pre-classify to copy the TOS values to the VPN packet's TOS. NB: The copied TOS can be overwritten, but that won't change the original packet's TOS.
E.g. you have VoIP packets marked with TOS values (perhaps a DSCP EF) so QoS can give them better treatment. If the original packet's TOS isn't copied to the VPN packet's TOS, QoS could no longer tell the difference between VoIP packets and FTP packets since they are now likely to be encrypted. (Pre-Classify is the command to cause the copy.)

Configuring QoS for FIOS Router MI-424WR: Traffic Priority and Shaping

Please only read on if you are an experienced internet user familiar with setting the advanced QoS and Firewall settings for the MI-424WR and make use of wireless adaptors from a PC to provide connectivity.
This is my first post and my first week since I moved from Time Warner Cable over to FIOS for iNet (plus HDTV and phone).     While all my services work, the router as delivered and setup is not optimum for internet quality of service. Instead it was probably out of the box optimized for HDTV and telephone to satisfy most customers and reduce support overhead.   The average FIOS consumer is multimedia sensitive, but that is not so in my genre of internet consumer.   Here in lies the core of my reason for seeking help from like minded and experienced users in this community.
One of the main driving forces in my switching to FIOS was to improve my multiplayer gaming experience where ultra low ping latency and high upload data rates dramatically affect the quality of connection and thus gameplay.    The cable internet service from TimeWarner was providing solid 2MB/1MB down/up data rates with no issues like what Im having now with FIOS.   Again the reason for the switch was both financial and in hope of gaining better data rates and quality of service.   Now with FIOS Im getting about 24/15 down/up data rate on the Extreme FIOS 25/25 plan when measured from my house to Los Angeles server (50 miles away) via Speedtest.net or DslReports.com/tests.     Latency wise, the ping has gone down from 150 to 50ms when measured to my friends who I connect to online that are on the East coast.   The data rate and latency has greatly improved in going from Cable to FIOS.   So far, so good.
Where the problem shows up now, is that now I get an internet "hiccup" every 5-10 minutes that lasts about 1/2 to 2 seconds.   For the average internet user that just streams multimedia or cruises on the net; this is probably undetectable or noticed.   I never had this problem over the same PCs connected wirelessly to my DLINK DGL-4500 Gaming Router when my ISP was TimeWarner's cable service.    Now, using the FIOS and MI-424WR router with everythings being the same; Im experiencing this degregation in quality of service.    Even putting the PC's IP into the DMZ doesnt make any difference, so it is not related to port forwarding.    The issue is squarely in the lap of FIOS and this router as delivered and configured.    This is where the "game" is a foot, and where I need expertise in an area Im new to.
I am not new to being hands on with inet trouble shooting asI have been setting up my own home network (I work from home over VPN to work) for decades; I would like to leverage the skills of those who are experts in the area that I think can address this issue.   That being QoS and the other device class mechanisms of this router.   Its my guess that this periodic hiccup can be minimized and even eliminated using these advanced features of this all-in-one TV/iNet/Tele router.
With that context being laid down, this hiccup doesnt show up if:
a. I connect two PCs connected to the same ethernet hub of the MI-424WR (traffic just over the LAN and not WAN)
b. When I was on Cable with my own gaming router wirelessly DHCP connected to my PC and using port forwarding or using the DMZ.
The hiccup does exist when:
a.  Going from internet through the MI-424WR to the wireless DHCP connected PC with port forwarding
b. Even putting the wireless DHCP connected PC into the MI-424WR's DMZ has no effect
I did read the manual and tried some QoS pritority and shaping and managed to reduce how often the hiccup occured, but I was just making guesses at the settings.   I put in the IP for the PCs I use for my gaming applications (which are very ping and jitter sensitive) into the QoS priority (value 7) and shaping GUI.    Im hoping someone with experience can tell me exactly how to use it and what settings to input.   Im not clear on the device and connection types offered in the QoS menus.
Another thing, is I couldnt find settings for the turning on/off the ICMP echo.   But I assume this is on because it can be pinged by folks on the net to my WAN IP.
Here is the manual for the Verizon provided M424WR router (Current Version of firmware: 20.10.7)
download link
Here are the QoS traffic priority and shaping values Ive been experimenting with:
Click to view QoS Traffic Priority
Click to view QoS Traffic Shaping
And why it matters to have a solid and stable inet connection for internet gaming? The hiccup causes slewing or jitter which equates to positional errors in the 3D world that ruins the smooth gameplay that is needed for high end gaming.
Heres a snapshot of me flying the wing of another flight simmer who is on the East coast and me on the West coast.
Click to view
Thank you in advance.
Thomas "AV8R"
MSEE

TMAS wrote:
the router as delivered and setup is not optimum for internet quality of service. Instead it was probably out of the box optimized for HDTV and telephone to satisfy most customers and reduce support overhead.
That's not accurate. VZ telephone service does not go through the Actiontec. Also, there are no default settings for QOS in the Actiontec since QOS is rarely needed with FIOS upload speeds.
TMAS wrote:I get an internet "hiccup" every 5-10 minutes that lasts about 1/2 to 2 seconds.
   You should not be experiencing periodic "hiccups". Something is clearly amiss.
TMAS wrote:
With that context being laid down, this hiccup doesnt show up if:a. I connect two PCs connected to the same ethernet hub of the MI-424WR (traffic just over the LAN and not WAN)
The hiccup does exist when:
a.  Going from internet through the MI-424WR to the wireless DHCP connected PC with port forwarding
b. Even putting the wireless DHCP connected PC into the MI-424WR's DMZ has no effect
Lets see. The issue shows up on a wireless connection, but not a wired connection. You think this is a QOS issue and not a wireless issue why? Have you tried changing the wireless channel? It very possible you have neighbors on the same channel. Is the DGL-4500 wireless still on? Could that be interfering?TMAS wrote:
Another thing, is I couldnt find settings for the turning on/off the ICMP echo.
The settting to enable/disable ICMP echo is on the Firewall/Remote Administration page.
TMAS wrote:
Here are the QoS traffic priority and shaping values Ive been experimenting with:Click to view QoS Traffic Priority
Click to view QoS Traffic Shaping
The traffic proirity settings you linked are applied only to your wireless connections. QOS between the router and your wireless PC will only serve to prioritize traffic between the router and that PC and have no affect on your internet traffic. Assuming you are not running browsers, VOIP and other traffic from that PC while you're gaming, then that will not accomplish anything. i.e. You're giving your only traffic highest priority, but that traffic is not competing with anything (except other nearby wireless connections on the same channel).
On the traffic shaping screenshot, you have broadband ethernet checked, but according to your other thread, your WAN connection is Broadband Coax, not Broadband ethernet.

Ip sla operations with different keys for the same destination

Hi all,
the customer wants to use different ip sla operations for the same destination (ip sla responder). From the first source router he uses key key1 and from the second source router he uses key key2. The ip sla responder responds only for the first router which uses the key key1.:-( Is it a normal behaviour? Can I use different keys for different ip sla operations for the same ip sla responder?
See the configuration on the responder:
key chain test
key 1
key-string 7 *key1*
key 2
key-string 7 *key2*
ip sla key-chain test
ip sla responder
He tried to use ip sla responders on:
Ciscu 2911
Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.2(4)M3, RELEASE SOFTWARE (fc2)
Cisco 881
Cisco IOS Software, C880 Software (C880DATA-UNIVERSALK9-M), Version 15.1(4)M4, RELEASE SOFTWARE (fc1)
Thank you.
Roman

Thomas,
Have a look at:
http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_dmvpn/configuration/15-2mt/sec-conn-dmvpn-share-ipsec-w-tun-protect.html#GUID-2B448241-FD10-4F3B-BFF8-DFD44982D235
If you're using one tunnel source you need to use one ipsec profile, unless you're running (a) p2p tunnel which you're not in this case.
While you MAY have some luck with sharing/unsharing among different interface I'm afarid it will not be ever mentioned as supported.
The situation will change with upcomfing 3.10 and 3.11 IOS XE releases (and corresponding IOS releases).
M.

IP SLA responder QoS ToS value

Similar Messages

Maybe you are looking for