[c-nsp] ipsla - latency - related to cellular backhaul

[Aaron]

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:sledge121 at gmail.com] 
Sent: Friday, April 26, 2013 6:27 AM
To: Tony
Cc: Aaron; cisco-nsp at puck.nether.net
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 <td_miles at yahoo.com> wrote:

Hi,




>________________________________
> From: Aaron <aaron1 at gvtc.com>

>
>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  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/