Hello P.bevilacqua:

The origin interface on the IP SLA sender is GEth.

The destination interface (SLA receiver, at the other side of the service provider WAN) is a loopback interface.

My client's sender router and the service provider CPE are linked by an ethernet VLAN. The service provider router has the aforementioned GE interface plus an ATM WAN interface. On the ATM WAN interface the service provider rates and polices the output (WAN bounded) packets.

Some time ago I thought that it could be necessary to include any packet overhead to the calculation, but I supposed that worst case I should have included 14 bytes of the ethernet header.

But then I thought the ethernet header should not be included because as I said before the policing is carried out in the ATM interface that looks to the service provider WAN. On this interface the ethernet header that my router includes to every IP SLA packet should be meaningless.

But even though I included the 14 bytes of the ethernet header, every packet should now be 180+14= 194 bytes. 194*100 packets per seconds times 8 bits per packet times 5 operations should give me an aggregated rate of 776000 bps, that is still well below the 958000 bps that the service provider's policer detects.

So I sill have no clue about this difference.

Please let me know if I can provide you with more information.

Best regards, Rogelio

Yes, it makes perfect sense!

In fact, I was puzzled because I tried the same routines on the network of another service provider, but this other WAN is based on Metro Ethernet, so I do not have this overhead and no single packet was lost.

Thank you very much for your hints. Now I have something to work with an arrive to the solution :o)

regards, Rogelio

Since your SP appears collaborative, ask to switch to vcmux encap to save 8 bytes.

cRTP would be a bigger optimization but it requires PPP and CPU processing so that is less likely to be welcome.

Thanks for the nice rating and good luck!

Hello P.bevilacqua:

cRTP is not possible because the ATM interface is actually the entry point to an MPLS network, and although I heard that cRTP over MPLS has already been specified (and I guess implemented on Cisco routers), this provider is a little bit behind these kind of optimizations.

Thanks a lot again, Rogelio

Hi, in a traditional cisco router crtp would be just a link feature. It ends there on the interface and doesn't matter if there is mpls or whatever else.

But because it has interoperability issues, and can impose additional load on the router one way or another, SPs are reluctant to use it. So it's more a feature for enterprise private circuits.

One great saving bandwidth saving that you can also try, is the modern and netwok-aware codec: iLBC. It has excellent voice quality, low bitrate and copes well with jitter and packet loss. It is supported on cisco voice GWs and the latest models of phones.

Thanks again and good luck!

Hello P.Bevilacqua:

I built a tiny lab with an IP SLA sender, an IP SLA responder, and a sniffer.

I found something strange. Even though I asked the jitter operation to pace packets at 10msec each, my sniffer shows me that 27000 packets were sent in aprox 220 seconds (I can also confirm this because I see the leds on the interface when the router starts sending and when stops it) although actually this operation should have taken 270 seconds to be executed.

I repeated this operation many times, so I am pretty sure that "something else" is going on. ¿Could it be possible that the IP SLA sender is not following the 10msec interval rule I programmed for this operation?

In other words, ¿should the router pace them strictly at 10msec as I expect or I am missing the meaning of the "interval" parameter in the jitter operation?

regards, Rogelio

Hi, I've never practiced much with ip sla. Sure it can have bugs and I remember at least one case where it caused high cpu utilization.