I don't see a codec option in ios xr 4.1.2
RP/0/RSP0/CPU0:9k(config-ipsla-udp-jitter)#? clear Clear the uncommitted configuration commit Commit the configuration changes to running control Control packets configuration datasize Protocol data size in payload of probe packets describe Describe a command without taking real actions destination Address/port of the target device do Run an exec command exit Exit from this submode frequency Frequency of the probing no Negate a command or set its defaults packet Probe packet configuration parameters pwd Commands used to reach current submode root Exit to the global configuration mode show Show contents of configuration source Address/port of the source device statistics Statistics collection parameters for this operation tag Add a tag for this operation timeout Probe/Control timeout interval tos Type of service setting in probe packet verify-data Check each IPSLA response for corruption vrf Configure IPSLA for a VPN Routing/Forwarding instance From: Richard Clayton [mailto:[email protected]] Sent: Friday, April 26, 2013 6:27 AM To: Tony Cc: Aaron; [email protected] Subject: Re: [c-nsp] ipsla - latency - related to cellular backhaul I would use udp-jitter, like this ip sla 1 udp-jitter 1.1.1.1 16384 codec g711alaw codec-numpackets 600 codec-interval 100 tos 184 tag "probe my remote site" ip sla schedule 1 life forever start-time now The tos is optional, we use it to test for voice media quaility, udp traffic should not suffer the same as icmp On 26 April 2013 00:35, Tony <[email protected]> wrote: Hi, >________________________________ > From: Aaron <[email protected]> > >Tac says that this drop and the latency seen using various ipsla pings is >expected since all pings are treated less than everything else and could be >getting policed by LPTS (I don't know what LPTS is) > Google tells me that LPTS = Local Packet Transport Services. TAC are meaning packets that are destined for the router control plane, not the forwarding plane (ie. packets TO the router, not THROUGH the router). Response to these packets can depend on how busy the router is and also any CoPP that might be implemented. Has potentially to be true. If you have no CoPP on the devices and they are under minimal load (CPU wise) then this probably shouldn't be a factor. Are you losing any traffic that is going through the device (ie. from ping tests) ? regards, Tony. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
