Daren Matthews

Planning for Voice over IP requires an understanding of the various headers added when transporting packetised voice, espcially over an IPSec VPN:

Voice overhead as a result of encapsulation

Packet Size—IPSec Encrypted G.729

The Layer 3 data rate for a G.729 call (50 pps) is 24 Kbps. Encrypting that packet using IPSec Tunnel mode for IP GRE increases that rate to approximately 56 Kbps (in each direction). The calculation is as follows:

• 136 bytes per packet at 50 packets per second = 6,800 bytes or 54,400 bits per second

Packet Size—IPSec Encrypted G729

Packet Size—IPSec Encrypted G.711

The Layer 3 data rate for a G.711 call (50 pps) is 80 Kbps. Encrypting that packet using IPSec Tunnel mode for IP GRE increases that rate to approximately 112 Kbps (in each direction). The calculation is as follows:

• 280 bytes per packet at 50 packets per second = 14,000 bytes or 112,000 bits per second

Packet Size—IPSec Encrypted G711

IPSec and GRE Tunnel Design Considerations

There are currently three recommended design options for a site-to-site IPSec VPN:

1. IPSec Tunnel mode—no IP GRE tunnel
2. IPSec Transport mode encrypting an IP GRE tunnel
3. IPSec Tunnel mode encrypting an IP GRE tunnel (primary recommendation)

IPSec Tunnel mode is the default configuration option. To configure Transport mode, it must be specified under the transform set:

!

crypto ipsec transform-set vpn-test esp-3des esp-sha-hmac

mode transport

!

The advantages, disadvantages and features and limitations of these options are as follows:

IPSec Tunnel mode—no IP GRE tunnel.
This does not utilise a GRE tunnel. IPSec encrypts IP unicast traffic only, IP Multicast traffic cannot be transported between the IPSec peers without configuring an IP GRE tunnel. This configuration might be sufficient to support the application requirements and its advantage lies in less CPU overhead (primarily at the head-end router) to maintain a IP GRE tunnel to each remote location and a routing protocol’s hello and update packets. IPSec security associations are created for each access list line matched. An access list must be specified in the crypto map to designate packets that are to be encrypted. The access list (when encrypting an IP GRE tunnel) is only one line, a match on protocol 47 (GRE) and the source and destination IP address of the GRE endpoints.

IPSec Transport mode encrypting an IP GRE tunnel.

This option is commonly implemented; for a G.729 packet it saves 16 bytes per packet over IP GRE tunnels with IPSec Tunnel mode, as an additional IPSec IP header is not required. IPSec Transport mode saves link bandwidth, but it does not provide any reduction in packets per second switched by the router. In most instances, packets per second, not packet size, is the limiting factor of a router’s main CPU performance.

Configuring IPSec Transport mode to encrypt an IP GRE tunnel provides all the advantages of using IP GRE—it supports IP Multicast, routing protocols and multi-protocol support.

IPSec Tunnel mode encrypting an IP GRE tunnel.

This option is implemented in this design guide and in the associated lab testing. It incurs the greatest header overhead of the three options, but it is capable of supporting IP Multicast and the ability to run a dynamic routing protocol within the IP GRE tunnel for failover to an alternative path. It supports Pre-fragmentation for IPSec VPNs. This option was selected for lab testing as it provides the greatest features and flexibility as well as the worst-case scenario in our performance testing in regards to bandwidth consumption.

IPSec Transport vs. Tunnel Mode for G.729 Packets

When configured with a routing protocol running within an IP GRE tunnel, the routing protocol’s hello packets maintain the security associations between both (assuming a redundant configuration) head-end routers. There is no need to create a security association to a back-up head-end peer upon failure of the primary peer.

Also, routing protocol hello timers (5 seconds by default for EIGRP) can be tuned lower than the hello interval of Internet Security Association and Key Management Protocol (ISAKMP) keepalives—the minimum value is 10 seconds.

Detection of a failed head-end peer is quicker when using a routing protocol verses crypto isakmp keepalive 10—the dead interval for ISAKMP keepalive is 3 times the keepalive value, or 30 seconds. EIGRP has a default dead interval of three times the hello value of 5 seconds, or 15 seconds.