Cisco Support Community
Community Member

VOIP Per Call Bandwidth consumption running over LAN-to-LAN on IPSec connec

As stated (by cisco) g.711 requires 80kbps (G711 / Payload 160 Bytes).

But what part of IPSec/ESP is added (overhead) when running over the LAN-to-LAN IPSec connection.

The case is that I see 85kbps for 1 call on my policy-map (see output/config below for details)

The 80kbps bandwidth per call consist of:

50pps x (8 bit/bytes x (20bytes IP Header + 8bytes UDP + 12bytes RTP + 160bytes Voice) = 80Kbps

But what IPSec/ESP part/bytes is added (adding the extra 5Kbps ~ 12 Bytes): ??????


Sequence Number ?

IV ?

Padding ?

Pad Length/Next Header ?

Authentication Data ?


Class-map: VOIP-EF (match-any)

5 minute offered rate 85000 bps

Match: protocol rtp audio

interface FastEthernet

service-policy output Class-map-VOIP-EF

crypto map VPN-L2L


crypto isakmp policy 1

encr aes 256

authentication pre-share

group 5

crypto isakmp key >secret> address

crypto isakmp keepalive 10


crypto ipsec security-association lifetime seconds 28800


crypto ipsec transform-set TS-VPN-L2L esp-aes 256 esp-sha-hmac


crypto map VPN-L2L 1 ipsec-isakmp

set peer

set transform-set TS-VPN-L2L

match address 110

qos pre-classify

Community Member

Re: VOIP Per Call Bandwidth consumption running over LAN-to-LAN

I believe the IPSec overhead is added after the traffic is queued.

The 85k is voice traffic. This traffic is encapsulated just before being sent over the network.

Use 'show interface' to measure the amount of bandwidth being used on the wire.

Community Member

Re: VOIP Per Call Bandwidth consumption running over LAN-to-LAN

Welcome to voice over secure networks. :-) It's not all that bad once you get used to it.

The numbers I use are 32 bytes per packet for IPSec transport mode, 84 bytes for IPSec tunnel mode with AH. If you have GRE (for voice, it comes in handy) we add an additional 24 bytes.


Community Member

Re: VOIP Per Call Bandwidth consumption running over LAN-to-LAN

Oh, as a seperate note...

The easiest way to get these numbers is to break out a sniffer and run some captures. The information on the web for this topic can be misleading, and just plain inaccurate at times.

On top of that, Cisco changes IPSec modes without reporting it, causing problems for voice if the line is under heavy load. Look up "no crypto ipsec nat-transparency udp-encaps" as an example of Cisco's sabotage of their customer's voice over secure networks.

I'm being a bit rough on Cisco with that last statement, it seems like every network vendor out there goes out of their way to make it extremely difficult to run voice over anything other than unsecured MPLS. Due to company audit policies, we secure everything on the network, credit card numbers, financial transactions, engineering data, all intelectual property, and that includes voice as well.

Finding a network equipment vendor that will help accomplish that isn't easy. Cisco's the best of the available options.

Voice and video with QOS over encrypted can be done, in spite of how much network vendors do to try to keep it from working.


CreatePlease to create content