I didnt realise you were using XR, you should be able to finish the operation off by selecting other options from the list.
On 26 April 2013 13:48, Aaron <[email protected]> wrote: > 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/
