Cisco AAVID Enterprise VPN Design

Cisco AVVID Network Infrastructure
Enterprise Site-to-Site VPN Design

Solution Reference Network Design
Corporate Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 526-4100
Customer Order Number: 956377

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL
STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT
SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE
OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public
domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH
ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT
LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF
DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING,
WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO
OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
y g y p g g
Expertise, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, Networking Academy, ScriptShare, SMARTnet, TransPath, and Voice LAN are trademarks of Cisco Systems,
Inc.; Changing the Way We Work, Live, Play, and Learn, Discover All That’s Possible, The Fastest Way to Increase Your Internet Quotient, and iQuick Study are service marks of
Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo,
Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, GigaStack, IOS,
IP/TV, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, StrataView Plus, Stratm,
SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.
All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship
between Cisco and any other company. (0201R)
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

Copyright © 2002, Cisco Systems, Inc.
All rights reserved.
C ON T E N T S
Preface vii
Scope vii
Intended Audience vii
Obtaining Documentation viii
World Wide Web viii
Documentation CD-ROM viii
Ordering Documentation viii
Documentation Feedback viii
Obtaining Technical Assistance ix
Cisco.com ix
Technical Assistance Center ix
Cisco TAC Web Site x
Cisco TAC Escalation Center x
CHAPTER 1 Cisco AVVID Network Infrastructure VPN Solution Overview 1-1

Site-to-Site VPN Benefits 1-2
References and Reading 1-3
CHAPTER 2 Enterprise Site-to-Site IPSec VPNs 2-1

Solution Overview 2-3
Starting Assumptions 2-3
Design Overview 2-3
Cisco VPN Product Overview 2-5
Solution Design Recommendations 2-6
General Design Considerations 2-7
Solution Characteristics 2-8
IPSec for Data Encryption 2-9
Implementing Generic Route Encapsulation (GRE) 2-9
Ensuring High Availability and Resiliency 2-10
Head-end Load Distribution 2-11
Number of Tunnels per Device 2-12
Alternative Network Topologies 2-13
Using a Routing Protocol Across the VPN 2-13
Route Propagation Strategy 2-13

EDCS-202049 iii
Contents
Alternatives to Using a Routing Protocol 2-16

Layer 3 Fragmentation 2-17
Path MTU Discovery 2-18
Planning for Security 2-18
Placement of VPN Head-ends Relative to Firewall 2-18
Split Tunneling 2-19
Supporting Multicast 2-19
IPSec Interactions with Other Networking Functions 2-19
Routing Protocols 2-19
IP Addressing 2-19
Network Address Translation (NAT) and Port Address Translation (PAT) 2-20
Dynamic Host Configuration Protocol (DHCP) 2-20
Service Provider Dependencies 2-20
Management 2-21
Solution Component Recommendations 2-21
Scalability Testing Methodology 2-21
Hardware-Accelerated Encryption 2-22
Head-end Devices 2-23
Sizing the Head-end 2-23
Cisco VPN Routers for Head-ends 2-26
New Cisco Head-end Products 2-27
Other Cisco Products 2-27
Branch Site Devices 2-27
Sizing the Branch Site 2-27
Cisco VPN Routers for Branch Sites 2-28
New Cisco Branch Site Products 2-29
Other Cisco Products 2-29
Network Performance/Convergence 2-29
Software Releases Evaluated 2-30
Additional Considerations for Latency-Sensitive Traffic 2-30
Quality of Service (QoS) 2-31
Pre-classification of Traffic 2-31
Lower Link Speeds 2-31
Hardware-Accelerated versus Software-Based Encryption 2-32
Compressed RTP Not Supported by IPSec 2-32
Additional Service Provider Considerations 2-32
Enterprise Site-to-Site VPN Case Study 2-33
Enterprise Organization Overview 2-33
Design Considerations 2-35

iv EDCS-202049
Contents
Preliminary Design Considerations 2-35

Sizing the Case Study Head-end 2-36
Sizing the Case Study Branch Sites 2-37
Tunnel Aggregation and Load Distribution 2-37
Network Layout 2-38
Configuration Discussion 2-39
IKE Policy Configuration 2-39
IPSec Transform and Protocol Configuration 2-40
Access List Configuration for Encryption 2-40
Crypto Map Configuration 2-41
Applying Crypto Maps 2-41
Dynamic Crypto Maps 2-42
Common Configuration Mistakes 2-43
ACL Mirroring Error 2-43
Peer Address Mismatch 2-43
Transform Set Mismatch 2-43
IKE Policy Mismatch 2-43
APPENDIX A Enterprise Site-to-Site VPN Scalability Test Configuration A-1

Scalability Testbed Network Diagram A-1
Scalability Testbed Configuration Files A-3
Head-end Configuration A-3
Branch Site Configuration A-5
APPENDIX B High-Level IPSec Overview B-1

Tunneling Protocols B-1
Introduction to IPSec B-1
IPSec Protocols B-2
Encapsulating Security Protocol (ESP) B-2
Authentication Header (AH) B-4
IPSec Modes B-5
Tunnel Mode B-5
Transport Mode B-6
Internet Key Exchange (IKE) B-6
Security Association (SA) B-7
IKE Phase 1 B-7
IKE Phase 2 B-7
IKE Authentication B-7
Pre-shared Keys B-7

EDCS-202049 v
Contents
Digital Certificates B-8
INDEX

vi EDCS-202049
Preface
This preface summarizes the following general topics:

• Scope
• Intended Audience
• Obtaining Documentation
• Obtaining Technical Assistance
Scope
This publication defines the comprehensive functional components required to build a Site-to-Site
Enterprise Virtual Private Network (VPN) solution.
Cisco Solutions Engineering is dedicated to producing high quality, tested designs that are intended to
help deploy the solution product set with confidence. This publication is part of an ongoing series that
addresses VPN solutions, using the latest VPN technologies from Cisco, and based on practical design
principles that have been tested to scale.
This publication focuses on Enterprise site-to-site Virtual Private Networks (VPN) solutions. It
addresses the following solution characteristics and technologies:
• IP Security (IPSec) in combination with Generic Routing Encapsulation (GRE)
• Site-to-site VPN topologies
• Cisco VPN routers running Cisco Internetwork Operating System (Cisco IOS)
• Use of Enhanced Interior Gateway Routing Protocol (EIGRP) as a routing protocol across the VPN
• Data as the primary traffic component
• Evaluation of Cisco VPN product performance in scalable and resilient designs
Intended Audience
This document covers site-to-site VPN design, planning, and implementation in Enterprise
environments. Intended audiences include:
• Cisco Systems Engineers (SEs) and Customer Support Engineers (CSEs)
• Customer and partner network designers, architects, and managers

EDCS-202049 vii
Preface
Obtaining Documentation
Obtaining Documentation
The following sections explain how to obtain documentation from Cisco Systems.
World Wide Web

You can access the most current Cisco documentation on the World Wide Web at the following URL:
Translated documentation is available at the following URL:
http://www.cisco.com/public/countries_languages.shtml
Documentation CD-ROM
Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM
package, which is shipped with your product. The Documentation CD-ROM is updated monthly and may
be more current than printed documentation. The CD-ROM package is available as a single unit or
through an annual subscription.
Ordering Documentation
Cisco documentation is available in the following ways:
• Registered Cisco Direct Customers can order Cisco product documentation from the Networking
Products MarketPlace:
http://www.cisco.com/cgi-bin/order/order_root.pl
• Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription
Store:
http://www.cisco.com/go/subscription
• Nonregistered Cisco.com users can order documentation through a local account representative by
calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, elsewhere in North
America, by calling 800 553-NETS (6387).
Documentation Feedback
If you are reading Cisco product documentation on Cisco.com, you can submit technical comments
electronically. Click Leave Feedback at the bottom of the Cisco Documentation home page. After you
complete the form, print it out and fax it to Cisco at 408 527-0730.
You can e-mail your comments to bug-doc@cisco.com.

viii EDCS-202049
Preface
Obtaining Technical Assistance
To submit your comments by mail, use the response card behind the front cover of your document, or
write to the following address:
Cisco Systems
Attn: Document Resource Connection
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.

Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can
obtain documentation, troubleshooting tips, and sample configurations from online tools by using the
Cisco Technical Assistance Center (TAC) Web Site. Cisco.com registered users have complete access to
the technical support resources on the Cisco TAC Web Site.
Cisco.com
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open
access to Cisco information, networking solutions, services, programs, and resources at any time, from
anywhere in the world.
Cisco.com is a highly integrated Internet application and a powerful, easy-to-use tool that provides a
broad range of features and services to help you to
• Streamline business processes and improve productivity
• Resolve technical issues with online support
• Download and test software packages
• Order Cisco learning materials and merchandise
• Register for online skill assessment, training, and certification programs
You can self-register on Cisco.com to obtain customized information and service. To access Cisco.com,
go to the following URL:
Technical Assistance Center

The Cisco TAC is available to all customers who need technical assistance with a Cisco product,
technology, or solution. Two types of support are available through the Cisco TAC: the Cisco TAC
Web Site and the Cisco TAC Escalation Center.
Inquiries to Cisco TAC are categorized according to the urgency of the issue:
• Priority level 4 (P4)—You need information or assistance concerning Cisco product capabilities,
product installation, or basic product configuration.
• Priority level 3 (P3)—Your network performance is degraded. Network functionality is noticeably
impaired, but most business operations continue.

EDCS-202049 ix
Preface
• Priority level 2 (P2)—Your production network is severely degraded, affecting significant aspects
of business operations. No workaround is available.
• Priority level 1 (P1)—Your production network is down, and a critical impact to business operations
will occur if service is not restored quickly. No workaround is available.
Which Cisco TAC resource you choose is based on the priority of the problem and the conditions of
service contracts, when applicable.
Cisco TAC Web Site

The Cisco TAC Web Site allows you to resolve P3 and P4 issues yourself, saving both cost and time. The
site provides around-the-clock access to online tools, knowledge bases, and software. To access the
Cisco TAC Web Site, go to the following URL:
http://www.cisco.com/tac
All customers, partners, and resellers who have a valid Cisco services contract have complete access to
the technical support resources on the Cisco TAC Web Site. The Cisco TAC Web Site requires a
Cisco.com login ID and password. If you have a valid service contract but do not have a login ID or
password, go to the following URL to register:
http://www.cisco.com/register/
If you cannot resolve your technical issues by using the Cisco TAC Web Site, and you are a Cisco.com
registered user, you can open a case online by using the TAC Case Open tool at the following URL:
http://www.cisco.com/tac/caseopen
If you have Internet access, it is recommended that you open P3 and P4 cases through the Cisco TAC
Web Site.
Cisco TAC Escalation Center

The Cisco TAC Escalation Center addresses issues that are classified as priority level 1 or priority
level 2; these classifications are assigned when severe network degradation significantly impacts
business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC
engineer will automatically open a case.
To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to the following
URL:
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml
Before calling, please check with your network operations center to determine the level of Cisco support
services to which your company is entitled; for example, SMARTnet, SMARTnet Onsite, or Network
Supported Accounts (NSA). In addition, please have available your service agreement number and your
product serial number.

x EDCS-202049
C H A P T E R 1
Cisco AVVID Network Infrastructure VPN
Solution Overview
This publication identifies the functional requirements to build Cisco AVVID Network Infrastructure
(Cisco AVVID NI) Virtual Private Network (VPN) solutions. It identifies individual hardware
components and their interconnections, software features, management needs, and service provider (SP)
dependencies necessary to facilitate deployment of a manageable and maintainable enterprise VPN
solution.
This chapter presents benefits and background information as a context for the design recommendations
presented in subsequent chapters.
Note This release of Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design focuses on
enterprise site-to-site implementation considerations. Information will be integrated emphasizing other
elements of VPN solutions as appropriate.
The design scheme presented is based on the Cisco SAFE VPN Architecture. This publication is
intended to provide an additional level of information on how to deploy Cisco SAFE VPN. The reader
should first be familiar with the Cisco SAFE VPN White Paper.
Cisco SAFE documentation can be found at the following URL:
http://www.cisco.com/go/safe
As an introduction to site-to-site VPN, this chapter presents the following specific topics:
• Site-to-Site VPN Benefits
• References and Reading

EDCS-202049 1-1
Chapter 1 Cisco AVVID Network Infrastructure VPN Solution Overview
Site-to-Site VPN Benefits
Site-to-Site VPN Benefits

This solution design offers a number of advantages over competing approaches to deploying site-to-site
VPNs. Table 1-1 summarizes primary benefits of deploying the solution described in this publication.
Table 1-1 VPN Solution Benefits Summary
Solution Design Criteria VPN Benefits

Security Traffic between branch offices and the central site
is encrypted using Triple Data Encryption
Standard (Triple DES).
High Availability A level of redundancy is provided at the head-end,
such that the design can tolerate a complete
failure of a head-end and recover quickly.
A dynamic routing protocol, such as Enhanced
Internet Gateway Routing Protocol (EIGRP), can
be used to manage network routing and provide
fast convergence.
Scalability A building-block approach to scalability is used,
such that the design can support thousands of
branch-offices, limited only by the number of
head-end devices deployed.
Scalability testing verified performance with up
to 240 branches per head-end device.
Flexibility Cisco VPN router product line allows
customization of head-end and branch office
routers.
Permits deployment of hardware-accelerated or
software-supported encryption. Use of
hardware-accelerated encryption is highly
recommended.
With generic routing encapsulation (GRE), it is
possible to build a VPN network that can handle
diverse network traffic requirements, including
multicast, multi-protocol, and network-layer
routing.
Reducing Costs Many VPN services offer the Enterprise some
level of cost reduction.

1-2 EDCS-202049
References and Reading

Table 1-2 and Table 1-3 provide references to related publications relevant when considering VPN
deployment.
Table 1-2 Request For Comment (RFC) Papers
RFC Topic
RFC2401 Security Architecture for the Internet Protocol
RFC2402 IP Authentication Header
RFC2403 The Use of HMAC-MD5-96 within ESP and AH
RFC2404 The Use of HMAC-SHA-1-96 within ESP and AH
RFC2405 The ESP DES-CBC Cipher Algorithm With Explicit IV
RFC2406 IP Encapsulating Security Payload (ESP)
RFC2407 The Internet IP Security Domain of Interpretation for ISAKMP
RFC2408 Internet and Key Management Protocol (ISAKMP)
RFC2409 The Internet Key Exchange (IKE)
RFC2410 The NULL Encryption Algorithm and Its Use With IPsec
RFC2411 IP Security Document Roadmap
RFC2412 The OAKLEY Key Determination Protocol
Table 1-3 Related Enterprise VPN Websites
Topic Link
Enterprise VPNs http://www.cisco.com/go/evpn
Cisco SAFE Blueprint http://www.cisco.com/go/safe
Cisco Network Security http://www.cisco.com/go/security
Cisco AVVID Partner Program http://www.cisco.com/go/securityassociates
Cisco VPN Product Documentation http://www.cisco.com/univercd/cc/td/doc/product/vpn/
Download VPN Software from CCO http://www.cisco.com/kobayashi/sw-center/sw-vpn.shtml
Improving Security on Cisco Routers http://www.cisco.com/warp/public/707/21.html
Essential Cisco IOS Features Every ISP http://www.cisco.com/warp/public/707/EssentialIOSfeatures_pdf.zip
Should Consider
Increasing Security on IP Networks http://www.cisco.com/cpress/cc/td/cpress/ccie/ndcs798/nd2016.htm
Cisco TAC Security Technical Tips http://www.cisco.com/warp/public/707/
IP Security (IPSec) Support Page http://www.cisco.com/cgi-bin/Support/PSP/psp_view.pl?p=Internetworking:IPSec
Networking Professionals Connection http://forums.cisco.com

EDCS-202049 1-3

1-4 EDCS-202049
C H A P T E R 2
Enterprise Site-to-Site IPSec VPNs
This chapter addresses network design considerations to deploy a site-to-site virtual private network
(VPN) based on IP Security (IPSec). Content here focuses on Cisco IOS VPN router products.
This publication defines a specific VPN design including a level of resiliency and support for
multi-protocols. The design presented is conservative, with an emphasis on engineering a
well-performing VPN based on verified parameters. The performance data presented is specific to this
design. Other designs are possible and may yield higher or lower performance.
The primary topology discussed is a hub-and-spoke deployment model, where the primary enterprise
resources are located in a large central site, with a number of smaller sites or branch offices connected
directly to the central site over a VPN. A high-level diagram of the network topology is shown in
Figure 2-1.

EDCS-202049 2-1
Chapter 2 Enterprise Site-to-Site IPSec VPNs
Figure 2-1 Hub-and-Spoke VPN
Medium sized
branches
Central site
Smaller
Internet branches
Corporate
network
Large
74167
branches
This chapter addresses enterprise site-to-site VPN design in the following sections:
• “Solution Overview” section on page 2-3
• “Solution Design Recommendations” section on page 2-6
• “Solution Component Recommendations” section on page 2-21
• “Additional Considerations for Latency-Sensitive Traffic” section on page 2-30
• “Enterprise Site-to-Site VPN Case Study” section on page 2-33
• “Configuration Discussion” section on page 2-39

2-2 EDCS-202049
Solution Overview
Solution Overview
This section provides an overview of the site-to-site VPN design topology and characteristics:
• Starting Assumptions
• Design Overview
• General Design Considerations
Starting Assumptions
The design approach presented in this publication makes several starting assumptions:
• The design supports a typical data traffic profile.
• Using the VPN for transport of IP telephony and video is not covered in this version of the
publication.
• High availability and resiliency after failover are critically important, therefore the
recommendations in this publication reflect the benefits of built-in resiliency and failover with fast
convergence.
• It is assumed that the network has a need for diverse traffic requirements, such as IP multicast,
multi-protocol, and/or support for routing.
• Cisco products in this publication are maintained at conservative CPU utilization levels.
• While costs were certainly considered, the design recommendations assume that the customer will
deploy current VPN technologies, including hardware-accelerated encryption.
• This design is targeted for deployment by enterprise-owned VPNs; however, the concepts and
conclusions are valid regardless of the ownership of the edge tunneling equipment and are therefore
also valuable for Service Provider (SP)-managed VPNs.
Design Overview
VPNs have many applications, including extending reachability of an enterprise WAN, or replacing
classic WAN technologies like Leased Line, Frame Relay (FR), and Asynchronous Transfer Mode
(ATM). Site-to-site VPNs are primarily deployed to connect branch office locations to the central site
(or sites) of an enterprise.
The requirements of enterprise customers for traditional private WAN services—such as multi-protocol
support, high availability, scalability, and security—are also requirements for VPNs. VPNs can often
meet these requirements more cost-effectively and with greater flexibility than private WAN services.
The key components of this site-to-site VPN design are the following:
• Cisco high-end VPN routers serving as VPN head-end termination devices at a central campus
(head-end devices)
• Cisco VPN access routers serving as VPN branch-end termination devices at branch office locations
(branch-end devices)
• IPSec and GRE tunnels that interconnect the head-end and branch-end devices in the VPN
• Internet services procured from a third-party ISP (or ISPs) serving as the WAN interconnection
medium

EDCS-202049 2-3
Solution Overview
Cisco VPN routers are a good choice for site-to-site VPN deployments because they can accommodate
most any network requirement inherited from the frame relay or private line network, such as support
for multicast and latency-sensitive traffic, routing for resiliency, and support for non-IP protocols like
IPX or SNA.
The network topology used to illustrate this design is shown below in Figure 2-2.
Figure 2-2 VPN Solution Network Topology
Central site
Branch
offices
Primary
ISP
Secondary
ISP
Corporate
network
IP Connectivity
74168
VPN Tunnel
The solution is a hub-and-spoke network with multiple head-end devices for resiliency. Head-ends are
high-end tunnel aggregation routers servicing multiple IPSec/GRE tunnels for a prescribed number of
branch office locations. In addition to terminating the VPN tunnels at the central site, the head-ends
together act as the distribution point for all routing information to and from branch-end devices.
Branch-ends are typically access routers that provide IPSec/GRE tunnel(s) for the branch office
locations to the central site. In addition to terminating the VPN tunnels, the branch-end often provides
WAN access and in some implementations can serve as a firewall.
To ensure authentication and encryption, IPSec tunnels are provisioned to interconnect branch offices to
the central site.
In order to provide a resilient network, this design implements a routing protocol across the VPN. Since
IPSec does not provide the ability to run protocols requiring IP multicast—such as Enhanced Interior
Gateway Routing Protocol (EIGRP)—IPSec is used in conjunction with GRE. GRE also provides the
ability for the customer to support more diverse traffic across the VPN, including IP multicast and non-IP
protocols.
For high-availability in the case of a failure, each branch-end access router should have two IPSec/GRE
tunnels, a primary and secondary, provisioned to two different head-end tunnel aggregation routers.

2-4 EDCS-202049
Solution Overview
There are several Service Provider (SP) options available to enterprise customers today for deploying a
VPN, including the enterprise owning and managing the VPN, seeking only Internet service from ISPs.
Optionally an enterprise can outsource its VPN to a SP. In general, the architecture and recommendations
provided in this publication are valid for either VPN deployment option— differing only in terms of edge
VPN equipment ownership.
This publication supports a wide variety of alternatives for deploying a flexible VPN solution that can
respond to changing customer requirements. However, the scale of deployment will affect products
selected and the configuration difficulty.
Cisco VPN Product Overview

The implementation presented in this publication is focused on using Cisco VPN router products in
IPSec-based VPN applications. Table 2-1 provides a summary of the recommended deployment of Cisco
VPN router product families to the different head-end and branch-office applications.
Table 2-1 Cisco VPN Product Applications Summary
VPN Router Maximum Scalability Traffic Mix

Application Family VPN Acceleration Options Performance1 Performance 2
Central Head-End Site Cisco 7200 ISA (single or dual), VAM Up to 140 Mbps Up to 40 Mbps3
Cisco 7100 ISM (single or dual), VAM Up to 140 Mbps Up to 30 Mbps4
Cisco 3600 AIM (Base, Medium, High Perform) Up to 38 Mbps Up to 16 Mbps
Large Branch Office Cisco 3600 AIM (Base, Medium, High Perform) Up to 38 Mbps Up to 16 Mbps
Cisco 2600 AIM (Base, Extended Perform) Up to 14 Mbps Up to 3 Mbps
Medium Branch Office Cisco 3600 AIM (Base, Medium, High Perform) Up to 38 Mbps Up to 16 Mbps
Cisco 2600 AIM (Base, Extended Perform) Up to 14 Mbps Up to 3 Mbps
Cisco 1700 VPN Module Up to 3 Mbps Up to 2.5 Mbps
Small Office Cisco 1700 VPN Module Up to 3 Mbps Up to 2.5 Mbps
Cisco 800 Not Available Up to 384 kbps Up to 100 kbps
1. Maximum performance evaluated with 1400-byte packet size, full CPU utilization, and single IPSec/GRE tunnel.
2. Scalability traffic mix evaluation performed with mixed packet sizes, 55 to 65 percent CPU utilization, and up to 240 IPSec/GRE tunnels (in head-end
case).
3. This is single ISA performance only. VAM performance with scalability traffic mix is currently under evaluation and will be published in a later revision
of this publication.
4. This is single ISM performance only. VAM performance with scalability traffic mix is currently under evaluation and will be published in a later revision
of this publication.
A number of new Cisco VPN router products were not available at the time of the scalability testing
performed with the design presented in this publication. These include the Cisco 7400, Cisco 3745,
Cisco 3725, and Cisco 1760 VPN routers. Refer to the section titled “New Cisco Head-end Products”
section on page 2-27 and “New Cisco Branch Site Products” section on page 2-29 for more information.
Additional Cisco VPN products, such as the Cisco PIX series and Cisco VPN 3000 Concentrator series,
will be included in this publication in a future version.

EDCS-202049 2-5
Solution Design Recommendations

In designing a VPN deployment, it is essential to integrate broader design considerations, such as high
availability and resiliency, security, and potentially quality of service (QoS).
This section starts with an overview of some general design considerations that need to be factored into
the design. This is followed by a summary of design recommendations, and then additional detailed
sections on these recommendations as required.
This section presents these considerations in the following specific sections:
• General Design Considerations
• Solution Characteristics
• IPSec for Data Encryption
• Implementing Generic Route Encapsulation (GRE)
• Ensuring High Availability and Resiliency
• Using a Routing Protocol Across the VPN
• Layer 3 Fragmentation
• Planning for Security
• Supporting Multicast
• IPSec Interactions with Other Networking Functions
• Service Provider Dependencies
• Management

2-6 EDCS-202049
General Design Considerations

Table 2-2 characterizes the general factors to consider when deploying a site-to-site VPN. Keep in mind
that this publication provides general design considerations. Each customer’s network can require
customization due to customer-specific requirements.
Table 2-2 General Site-to-site VPN Deployment Considerations
Solution Design Criteria Solution Question VPN Design Relevance

Network Profile What applications are expected The recommendations in this publication focus on data
to run over the VPN? applications. Multi-service applications such as IP
Telephony and video require additional design
considerations, such as QoS.
Is multicast and/or IPSec only supports tunneling of unicast-IP traffic.
multi-protocol support required? Multicast-IP is required to run a routing protocol across
the VPN and to support applications like video. GRE is
used in conjunction with IPSec to support multicast and
multi-protocols.
Does packet fragmentation need In some customer networks, the VPN design needs to
to be considered in the design? consider the amount of fragmentation that may occur.
Scalability How many branches are The number of branch offices, plus the amount of
expected to be aggregated to traffic expected from each branch, determines how
each central site? many head-end aggregation devices are required.
Improper aggregation can result in a VPN with
unacceptable performance.
What is the expected traffic The traffic throughput to/from branches has a direct
throughput between branch impact on the number of branches that should be
offices and the central site? aggregated by a head-end device. If not properly
considered, the resulting VPN design can have
unacceptable performance.
Resiliency What are the expectations for As in the case of a typical enterprise network, a VPN
resiliency? must be resilient to recover in the event of a failure. The
design discussed in this guide assumes a customer
requires redundancy at the central site that allows for
failover between head-end devices.
Security What type of Internet Key Different methods of IKE authentication necessitate
Exchange (IKE) authentication different levels of implementation complexity. For
method will be implemented? example, configuring pre-shared keys is the least
complex method, however scalability can be an issue.
Similarly, use of Certificates is highly scalable, yet they
are more complex to deploy.
Services What other services will run on VPNs can be deployed with dedicated function devices
the device? or as multiple function devices, providing WAN access,
firewall, and VPN services.

EDCS-202049 2-7
Solution Characteristics
Table 2-3 summarizes the best practices for deployment of an enterprise site-to-site IPSec-based VPN.
Table 2-3 Enterprise Site-to-site IPsec-based VPN Best Practice Summary
Deployment Objective Best Practice Summary

Designing the VPN Use IPSec (Tunnel Mode) with Triple Data Encryption Standard (Triple DES) for
encryption of data transported1. See “IPSec for Data Encryption” section on page 2-9 for
more information.
Use GRE tunnels so that multi-service protocols, such as multicast IP, and routing protocols,
such as EIGRP, are supported. See “Implementing Generic Route Encapsulation (GRE)”
section on page 2-9 for more information. Even if multi-protocol support is not a current
requirement, designing the VPN for future flexibility might prevent disruptive redesigns in
the future.
Configure two tunnels (primary and secondary) between each branch-end to different
head-end devices for failover resiliency. See “Ensuring High Availability and Resiliency”
section on page 2-10 for tunnel architecture recommendations.
Run a routing protocol with route summarization for dynamic routing. See “Using a Routing
Protocol Across the VPN” section on page 2-13 for more information.
Don’t use IKE keepalives. This is not necessary due to the use of a routing protocol.
Keep IPSec packet fragmentation at a minimum on the customer network. See “Layer 3
Fragmentation” section on page 2-17 for several mitigation strategies.
Consider the interactions of IPSec with other networking functions. See “IPSec Interactions
with Other Networking Functions” section on page 2-19 for more information.
Selecting Cisco VPN Products Deploy hardware-accelerated encryption in all products that support it. See
“Hardware-Accelerated Encryption” section on page 2-22 for more information.
Calculate the number of head-end devices based on total tunnel and throughput aggregation
requirements, as well as to handle failover. See “Sizing the Head-end” section on page 2-23
for recommendations on choosing the number of head-end devices.
Select Cisco VPN Router products at the head-end based on:
• Number of tunnels aggregated (scalability testing has verified performance up to 240
branches per head-end).
• Throughput aggregated up to the maximum recommendations for each product.
• Maintaining CPU utilization below 50 percent.
See “Sizing the Head-end” section on page 2-23 for head-end product recommendations.
Select Cisco VPN Router products at the branch offices based on the need to maintain:
• Throughput up to the maximum recommendations for each product
• Maintaining CPU utilization below 65 percent
• See “Sizing the Branch Site” section on page 2-27 for branch product
recommendations.
Use at least the minimum levels of Cisco IOS software as indicated in “Software Releases
Evaluated” section on page 2-30.
1. There are various laws and restrictions that govern domestic and international use and export of encryption technology.

2-8 EDCS-202049
Additional detailed information on these recommendations is discussed in the sections that follow, as
required.
IPSec for Data Encryption

There are three elements to consider when securing the traffic which flows over the VPN:
• Authentication—Ensuring the senders/receivers of traffic are known, valid entities
• Confidentiality—Encrypting data to render it imperceptible without the proper key
• Message Integrity—Identifying when data has been modified
To ensure confidentiality of data transported over the VPN, encryption algorithms such as Data
Encryption Standard (DES) or Triple DES are implemented. Since Triple DES is more secure, it should
be implemented if at all possible, except in cases where export restrictions limit the implementation to
DES.
To ensure message integrity, the IPSec protocol is used with a hash method, such as Message Digest 5
(MD5) or Secure Hash Algorithm 1 (SHA-1).
Note It is possible to implement only a hash method or only an encryption standard to secure the VPN.
However, it is highly recommended that both be implemented in combination. In this publication, the
combination of Triple DES and SHA-1 is recommended.
With hardware-accelerated encryption implemented, performance is not significantly affected by choice

of encryption method.
In the future, Advanced Encryption Standard (AES) will be another option for encryption of data.
Pre-shared keys were used in the evaluations for this publication. Use of Digital Certificates will be
addressed in a future version
Implementing Generic Route Encapsulation (GRE)

While IPSec provides a secure method for tunneling data across an IP network, it has several limitations.
First, IPSec does not support broadcast or multicast IP which prevents the use of protocols that rely on
their underlying features—such as routing protocols. Second, IPSec does not support the use of
multi-protocol traffic, such as IPX or SNA.
To overcome these limitations, implement GRE tunnels. GRE is a protocol that can be used to carry other
passenger protocols, such as unicast, broadcast or multicast IP, as well as non-IP protocols. This is shown
in Figure 2-3.
Figure 2-3 GRE as a Carrier Protocol of IP
IP GRE Network packet

74173
Transport Carrier Passenger

protocol protocol protocol

EDCS-202049 2-9
Using GRE tunnels in conjunction with IPSec extends the functionality of the VPN, so that multicast IP
can be supported on the network. This provides a critical element of the solution defined in this
publication. It enables the ability to run a routing protocol across the network between the central site
and branch offices.
Even if requirements such as multicast IP, non-IP protocols, or supporting routing protocols do not exist
in the current customer network, designing the VPN for greater flexibility prevents costly and potentially
disruptive re-designs if these capabilities become requirements in the future.
In a GRE-based environment, all traffic between sites is encapsulated in a GRE packet prior to the
encryption process. This simplifies the access list used in the crypto map statements since it requires
only one line permitting GRE (IP Protocol 47).
Ensuring High Availability and Resiliency

Data networks are often deployed as best effort networks. In such an arrangement, there is no guaranteed
network performance and frequently such networks are deployed with single points of failure. With
applications being increasingly dependent on network services, networks must be designed to behave in
a much more predictable manner. This includes recovery from failures within specific timeframes and
the ability to transport the packets to their destination with specific and repeatable (minimized) delays.
In all cases, networks should be designed so that the individual elements that make up the network are
operating in a resilient environment. These elements include network devices—such as routers and
switches—as well as the LAN and WAN links that connect these devices together.
In order to provide greater resiliency in the VPN design, Cisco recommends that two tunnels be
configured—a primary and secondary—between each branch-end device and the head-ends. Under
normal operating conditions, both the primary and secondary tunnels are established. The routing
protocol—such as EIGRP—maintains both routes, with the secondary tunnel configured as a less
preferred route. Figure 2-4 illustrates this configuration.

2-10 EDCS-202049
Figure 2-4 High-Availability Tunnel Configuration
Central site
VPN WAN
Head-ends interface Branch office
router Internet
Primary
Secondary
74174
Corporate
network
If a failure occurs at one of the head-end devices, the routing protocol detects that the route through the
primary tunnel is no longer valid, and after convergence the route through the secondary tunnel is used.
Once the primary is available again, traffic will be routed back to the primary tunnel as it is the preferred
route in the routing metrics.
The head-end resiliency design presented here allows for failure of a single head-end device, with proper
failover to surviving head-ends. This is normally adequate when the number of head-ends is relatively
low (such as ten or less). If the number of head-ends is relatively high (such as twenty or more), consider
designing for the possibility of multiple head-end device failures.
It might also be necessary to have head-end devices geographically dispersed. Although not specifically
tested, the architecture presented in this publication should readily support this configuration. More
information regarding this architecture is also discussed in the Cisco SAFE VPN White Paper. Cisco
SAFE documentation can be found at the following URL:
Configuration of primary and secondary tunnels to appropriate head-ends is critical to maintain network
resiliency.
Head-end Load Distribution

When laying out the network topology, be sure to consider load balancing across multiple head-end
devices—especially in the case of a head-end device failure. This design recommends at least two
tunnels configured between a branch device and the head-end. These guidelines should be followed:
• The primary tunnels should be configured to carry traffic under normal circumstances.
• The preferred primary tunnels should be evenly divided among the head-end devices.
• Secondary tunnels should be configured with a delay command statement to make the primary the
preferred tunnel route.

EDCS-202049 2-11
• The secondary tunnels for branches should be evenly spread among the remaining (surviving)
head-end devices.
It would be highly undesirable for all the tunnels from a failed head-end device to re-establish to a
single secondary head-end device when there are other devices available to distribute the load from
the failed device. Figure 2-5 illustrates a typical network topology with high resiliency.
Figure 2-5 Tunnel Aggregation for Resiliency
Head-end Primary Tunnels

devices
Secondary Tunnels
Branch
74175
office
devices
To plan for proper tunnel aggregation and load distribution in the case of a head-end device failure, the
following algorithm should be used:
1. Start with the number of total branch devices to be aggregated at the head-end.
2. Divide this number by the number of head-end devices.
3. Multiply the result by two for primary and secondary tunnels. This is the total number of tunnels per
head-end device.
4. Allocate the primary tunnels to each head-end device in the arrangement shown in Figure 2-5.
5. For each group, allocate the secondary tunnels in a round-robin fashion to all head-end devices
except the one serving as a primary for that group. This arrangement is also shown in Figure 2-5
above.
Please note that this calculation should take into account the amount of traffic being aggregated.
Adjustments might be necessary to account for tunnel throughput variances.
Number of Tunnels per Device

The number of tunnels required for each head-end device should be scaled to the overall size of the
network in which the VPN solution is being deployed. Please refer to “Sizing the Head-end” section on
page 2-23 for more information.
Note In testing the design presented in this publication, head-end scalability testing did not include an
exhaustive evaluation of the maximum number of tunnels that may be terminated to head-end devices.
In addition, scalability testing of branch site devices was performed with two tunnels per branch device
and did not include exhaustive testing of the number of tunnels these different platforms can support.

2-12 EDCS-202049
Alternative Network Topologies

The design presented in this publication is a typical hub-and-spoke topology. Other possible topologies
include partially meshed and fully meshed networks.
While these alternative topologies can be implemented in an IPSec VPN, they can increase the
complexity of the design and configuration due to the number of peers per device in such a network. For
example, the larger number of active tunnels per peer in a meshed network places a greater performance
burden on devices running IPSec—possibly requiring more CPU and memory resources.
The configuration of these devices also becomes more complex. At a minimum, an additional access list
must be created for each peer connection, as well as additional crypto map entries. A new feature named
Dynamic Multipoint VPN (mGRE+NHRP) will make such configurations easier in the future.
In addition, the routing protocol (as is recommended in this publication) must deal with many more
adjacencies, nullifying efficiencies associated with routing protocols, such as summarization and stub
features.
A fully meshed and partially meshed topology are possible, but like any network, these deployments
should be carefully designed and tested prior to roll out. Partial- and full-mesh topologies have not been
subjected to scalability testing for this publication.
Using a Routing Protocol Across the VPN

This design recommends the use of a routing protocol to propagate routes from the head-end to the
branch offices. Using a routing protocol has several advantages over the current mechanisms in IPSec
alone:
• VPN receives the same benefit as using routing protocols on a traditional network—this includes
receiving information about the network connectivity available over a particular interface, topology
information about a network, notification when that topology changes (such as when a link fails),
and information about the status of remote peers.
• While there are alternatives to using a routing protocol, most of these alternatives only offer the
ability to verify the health of the VPN device. With a routing protocol, it is possible to verify that
traffic is actually reaching its destination.
There are several routing protocols that are candidates for operation over the VPN, including EIGRP and
Open Shortest Path First (OSPF). The principles presented in this publication use EIGRP as the routing
protocol, as EIGRP was used during scalability tests conducted. EIGRP was selected due to its
conservative use of router CPU and network bandwidth as well as its quick convergence. EIGRP also
provides a range of options for address summarization and default route propagation.
Routing protocols do increase the CPU utilization on a network device and their use must be taken into
consideration when sizing those devices.
Route Propagation Strategy

There are a number of approaches to propagating routes from the head-end to the branch offices. For this
design, the recommended approach is for each head-end router to advertise a default route to each of the
terminated tunnels. The branch router will prefer the primary tunnel via a lower routing metric for the
primary path. Consider the example topology illustrated in Figure 2-6.

EDCS-202049 2-13
Figure 2-6 Route Propagation Example
Central site Branch office
VPN
Head-ends
131.108.251.2 Internet 131.108.153.2
Primary
Secondary
131.108.252.2
10.57.2.0 10.63.223.0
74603
In the example illustrated in Figure 2-6, the ISP has assigned public IP addresses 131.108.251.2 and
131.108.252.2 for our central site head ends and 131.108.153.2 for our branch office.
The corporate LAN at the central site is privately addressed as network 10.57.2.0, while the branch office
LAN is privately addressed as network 10.63.223.0.
The configuration excerpts presented in the following sections would be used to establish appropriate
tunnels and routing (assuming EIGRP as the routing protocol).
Head-end Router (Primary) Configuration Excerpt

interface Tunnel151
ip address 10.62.223.193 255.255.255.252
ip summary-address eigrp 1 10.0.0.0 255.0.0.0 5
tunnel source FastEthernet1/0
tunnel destination 131.108.153.2
crypto map static-map
!
interface FastEthernet1/0
ip address 131.108.251.2 255.255.255.252
duplex full
speed 100
!
description FastEthernet1/1
ip address 10.57.2.1 255.255.255.0
duplex full
speed 100
!
router eigrp 1
network 10.0.0.0
no auto-summary
eigrp log-neighbor-changes
!
ip route 0.0.0.0 0.0.0.0 131.108.251.1

2-14 EDCS-202049
Head-end Router (Secondary) Configuration Excerpt

interface Tunnel151
ip address 10.62.223.197 255.255.255.252
delay 60000
tunnel source FastEthernet1/0
!
ip address 131.108.252.2 255.255.255.252
duplex full
speed 100
!
ip address 10.57.2.2 255.255.255.0
duplex full
speed 100
!
router eigrp 1
network 10.0.0.0
no auto-summary
!
ip route 0.0.0.0 0.0.0.0 131.108.252.1
Branch Site Router Configuration Excerpt

Branch Site Router
interface Tunnel0
ip address 10.62.223.194 255.255.255.252
tunnel source Serial0/0
!
interface Tunnel1
ip address 10.62.223.198 255.255.255.252
delay 60000
tunnel source Serial0/0
!
interface Serial0/0
ip address 131.108.153.2 255.255.255.252
!
interface Ethernet0
ip address 10.63.223.1 255.255.255.0
!
router eigrp 1
network 10.0.0.0
no auto-summary
!
ip route 0.0.0.0 0.0.0.0 Serial0/0
IPSec/GRE tunnels are established using the public IP addresses as the tunnel sources and destinations.
The central site advertises a route for 10.0.0.0/8 to the branch office. The branch advertises a more
specific route for 10.62.233.0/24 to each head-end (primary and secondary).

EDCS-202049 2-15
Note that the branch office VPN router is configured with two tunnels—one to its assigned primary
head-end and one to its secondary (backup) head-end. The delay statement is used to slightly
differentiate the cost of the two routes, making the primary head-end the preferred route. The delay
statement must be applied on both the branch and head-end sides of the secondary tunnel.
A default route is also configured with the next hop address of the ISP. This is required in order for the
tunnel to be established. Once active, the more specific routes provided by dynamic EIGRP routing will
be used to actually route traffic to the appropriate VPN tunnel.
This example is intended to represent a fairly simple case with a single central site location and single
connection to the ISP. Depending on a variety of variables—such as the specific network topology,
connections to an ISP, the use of multiple central sites, and/or the use of multiple ISP connections—the
routing strategy might require additional analysis and planning.
For additional configuration issues, refer to “Configuration Discussion” section on page 2-39.
Alternatives to Using a Routing Protocol

For this publication, the approach recommended is the use of a routing protocol to propagate routes and
network state information between the central site and branch locations. There are several alternatives
to this approach:
• IKE Keepalives
• Dead Peer Detection (DPD)
• Reverse Route Injection
These alternatives are useful to consider because, if an IPSec peer fails, the other peer can continue
sending packets to that peer until the Security Association (SA) associated with that peer times out. To
avoid this black hole effect some sort of status update is needed.
Each of the three alternative to a routing protocol solution is discussed briefly in the sections that follow.
IKE Keepalives
IKE keepalives work by sending keepalive messages between IPSec peers whether or not a particular
peer has had any communications with its remote peer. The resulting messages and counters cause
significantly higher CPU utilization on IPSec devices, lowering the potential scalability. Using IKE
keepalives is therefore not recommended in this solution design.
Note The use of IKE Keepalives has not been evaluated for scalability as of this publication.
Dead Peer Detection (DPD)
Dead Peer Detection (DPD) is a relatively new Cisco IOS feature—targeted at providing efficient IPSec
peer state detection—as a better alternative to IKE Keepalives.
DPD works by sending keepalive messages to active IPSec peers that it has not received a message from
within a specified period of time. This results in a lower impact on the CPU utilization of the IPSec
device and corresponding higher potential scalability.
Note The use of IPSec DPD has not been evaluated for scalability as of this publication.

2-16 EDCS-202049
Reverse Route Injection
Another relatively new Cisco IOS feature is Reverse Route Injection. Reverse Route Injection functions
by taking the information derived from the negotiated IPSec SA's and injecting that information into the
routing protocol running on a particular router. This reduces the need to have a routing protocol running
across the actual VPN tunnels themselves.
One of the limitations of Reverse Route Injection is that it will only inject information derived from the
negotiated IPSec SAs. Any networks present that are not included in the access control list (ACL) that
is used for the IPSec policy would not be present in the injected routes.
As an example, consider an environment in which multiple networks are present behind a router
functioning as the VPN termination device. Each network must be specifically called out in the ACL
included in the crypto map statement if the networks are not summarized by that ACL.
Another example is the use of GRE tunnels for support of other protocols (such as multicast IP). The
ACL specified in the crypto map only lists the IP address of the GRE interface and the SA is not carrying
information about the network traffic carried inside the GRE tunnel.
Note The use of IPSec Reverse Route Injection has not been evaluated for scalability as of this publication.
Layer 3 Fragmentation
IPSec and GRE headers increase the size of packets being transported, as illustrated in Figure 2-7. If the
size of a packet before encryption is near the Maximum Transmission Unit (MTU) of the transmission
media, the encrypted packet with the additional IPsec and GRE headers can exceed the MTU of the
transmitting interface.
Figure 2-7 IPSec/GRE Packet Expansion
IP packet IP Hdr Data
20 bytes Large
GRE added New

GRE IP Hdr Data
IP Hdr
20 bytes 4 bytes 20 bytes Large
IPSec added New New

(tunnel mode) IPSec GRE IP Hdr Data
IP Hdr IP Hdr
20 bytes 32 bytes 20 bytes 4 bytes 20 bytes Large

variable
74176
MTU size

EDCS-202049 2-17
This resulting Layer 3 packet fragmentation requires these packets to be reassembled prior to the
de-cryption process. In Cisco IOS implementations prior to 12.1(11)E and 12.2(12)T, for some customer
networks this resulted in less than optimal throughput performance.
This is avoided by either:
1. Employing path MTU discovery (PMTU discovery). See “Path MTU Discovery” section on
page 2-18 for more information on this method.
2. Setting the MTU of attached workstations to allow for packet expansion, such as 1400 bytes.
For some customer networks, it might not be possible to easily manage MTU size. For these situations,
Cisco has implemented Pre-fragmentation for IPSec VPNs. This feature is available in Cisco IOS
12.1(11)E for head-end platforms and 12.2(12)T for branch platforms.
Path MTU Discovery

A feature of IP called path MTU discovery can eliminate the possibility of fragmentation if it is
supported by the end stations. This is a procedure that is run between two end stations with the
participation of the network devices between them.
During path MTU discovery, an MTU-sized packet is sent out by an end station with the don't fragment
(DF) bit set. If this packet encounters a link with a lower MTU than the packet size, an ICMP error
message is generated with a value of 3 in the type field (destination unreachable), a value of 4 in the code
field (fragmentation needed and DF set) and the next hop’s MTU size in the unused field of the ICMP
header.
In order for this process to work over an IPSec network with GRE, the GRE tunnel MTU should be set
to a value low enough to ensure that the packet will make it through the encryption process without
exceeding the MTU on the outbound interface—usually 1400 bytes.
Planning for Security

In planning for deployment of a site-to-site VPN topology, it is necessary to consider the integration of
enterprise network security functions. There are various enterprise security components that
complement and enhance the VPN solution.
For more information on how to integrate these essential security components, please refer to the Cisco
SAFE security blueprint and seminar series. Cisco SAFE documentation can be found at this URL:
Placement of VPN Head-ends Relative to Firewall

The placement of the VPN head-end devices in the network relative to the enterprise’s firewall can
critically affect the security of any VPN deployment.
Recommended architectures are discussed in the Cisco SAFE VPN White Paper. Cisco SAFE
documentation can be found at this URL:

2-18 EDCS-202049
Split Tunneling
Split tunneling is the process by which packets being transmitted from a site can be either protected by
IPSec or unprotected, depending upon their destination. When split tunneling is configured for a branch
site, that site must be protected by a stateful firewall.
Note Split tunneling has not been addressed within this design.
Supporting Multicast
The popularity of multimedia applications, such as video, has led many network administrators to
support multicast traffic on their networks. VPNs can also support these applications.
IPSec supports only tunneling of unicast IP traffic; therefore, it is necessary to implement GRE in
conjunction with IPSec to support multicast. See “Implementing Generic Route Encapsulation (GRE)”
section on page 2-9 for more information.
Note Multicast traffic is not currently supported by most firewalls. This would require the termination of the
IPSec tunnels on the inside interface of the firewall.
IPSec Interactions with Other Networking Functions

Because IPSec hides the packet and increases the packet size, interactions with other networking
functions must be taken into consideration. The following sections discuss various aspects to consider
when deploying site-to-site IPSec-based VPNs:
• Routing Protocols
• IP Addressing
• Network Address Translation (NAT) and Port Address Translation (PAT)
• Dynamic Host Configuration Protocol (DHCP)
Routing Protocols
All IP routing protocols use either broadcast or multicast as a method of transmitting routing table
information. Since IPSec does not support either broadcast or multicast, Cisco recommends using
Generic Routing Encapsulation (GRE) as a tunneling method to overcome this limitation. See
“Implementing Generic Route Encapsulation (GRE)” section on page 2-9 for more information on GRE
and “Using a Routing Protocol Across the VPN” section on page 2-13 for more information on running
a Routing Protocol across the VPN.
IP Addressing
Proper IP addressing is critical for a successful VPN. In order to maintain scalability, performance, and
manageability, it is highly recommended that remote sites use a subnet of the major network to allow for
summarization. This way the crypto Access Control Lists (ACLs) will contain a single line for every
local network; possibly a single entry if the local networks can be summarized.

EDCS-202049 2-19
Proper address summarization is highly recommended. Address summarization conserves router

resources making routing table sizes smaller. Address summarization also saves memory in routers, and
eases troubleshooting tasks. In addition to conserving router resources, address summarization also
simplifies the configuration of routers in IPSec networks.
Please consult the IP Addressing section of the Cisco SAFE VPN White Paper for a more thorough
discussion. Cisco SAFE documentation can be found at:
Network Address Translation (NAT) and Port Address Translation (PAT)

While Network Address Translation (NAT) and Port Address Translation (PAT) can result in an added
layer of security and address conservation, the presence of NAT or PAT in between IPSec peers presents
challenges to the implementation of an IPSec VPN.
In the case of PAT, IPSec peers with a PAT process between them will fail to negotiate properly. Internet
Key Management Protocol (ISAKMP) relies on an individual IP address per peer for proper operation.
PAT works by masquerading multiple peers behind a single IP address.
Site-to-site IPSec networks can operate between NAT processes. However, the un-translated peer must
be configured with the remote peer’s translated address for proper operation.
Dynamic Host Configuration Protocol (DHCP)

In order for a host at a remote site to be able to use a Dynamic Host Configuration Protocol (DHCP)
server over an IPSec tunnel at a central site, an IP helper address must be configured on the router
interface associated with the host.
Unfortunately, if connectivity to the central site is lost, a host at a remote site might not receive an IP
address. This can prevent the host from communicating with other hosts on its local network.
A Cisco IOS router can also be configured to act as a stand alone DHCP server; however, these features
have not been tested with IPSec VPN in preparing this publication version.
Service Provider Dependencies

VPNs inherently rely on one or more SPs to provide Internet service to the head-end and branch offices
in order to deploy the network, so choosing a SP is a critical element of deploying a VPN. Many factors
have to be considered including cost, services available, reliability, and the expected geographical
coverage of the customer’s VPN.
At a minimum, the enterprise should have a service-level agreement (SLA) with the SP that outlines the
critical service elements of its VPN. Factors to address include availability, bandwidth, and latency.
When the situation requires an enterprise to use multiple SPs to cover its branch locations, an added a
level of complexity can be imposed. Obtaining the desired level of end-to-end VPN service can be more
difficult—especially in a case involving delay-sensitive, mission-critical applications. Future
considerations of running latency-sensitive applications, such as IP Telephony and video, across the
VPN must also be considered.
For these reasons, Cisco recommends obtaining an SLA with a single SP that can guarantee adequate
end-to-end service for all enterprise locations.

2-20 EDCS-202049
Solution Component Recommendations
Another issue to be aware of is that some Internet SPs for DSL and cable services implement policing
of traffic for residential class service. This means that protocols such as IPSec might be blocked unless
a business class service subscription is established.
Management
Cisco brings all of its VPN products together through management systems that provide such status
information as device availability and throughput, for example, management integration through
products such as VPN/Security Management Solution (VMS) and VPN Solution Center (VPNSC).
A later version of this publication will discuss how Cisco brings together configuration management,
security policy management, quality-of-service management, and infrastructure management on Cisco
concentrators, routers, and firewalls.
For more information on how implement network management over IPSec tunnels, please refer to the
Cisco SAFE security blueprint and seminar series. Cisco SAFE documentation can be found at this URL:

This chapter presents the steps to selecting Cisco products for a deployable VPN solution, starting with
sizing the head-end, and then choosing Cisco products that can be deployed for head-end devices. It
concludes with product sizing and selection information for branch-end devices. Specific sections
include:
• Scalability Testing Methodology
• Hardware-Accelerated Encryption
• Head-end Devices
• Branch Site Devices
• Network Performance/Convergence
• Software Releases Evaluated
Scalability Testing Methodology

The scalability testbed included 240 branch offices aggregated to two head-end devices as illustrated in
Appendix A, “Enterprise Site-to-Site VPN Scalability Test Configuration.” Aggregation to three
head-ends was also tested for comparison purposes. The head-ends consisted of the Cisco 7100 and
Cisco 7200 Series VPN router products (see “Head-end Devices” section on page 2-23 for models
tested). The branch offices consisted of Cisco VPN router products from the Cisco 800, Cisco 1700,
Cisco 2600, and Cisco 3600 Series routers (see “Branch Site Devices” section on page 2-27 for models
tested).
Head-end products were evaluated with hardware-accelerated encryption installed, while branch
products were evaluated with both software-based encryption and hardware-accelerated encryption.
Triple DES was selected as the encryption standard and SHA-1 as the hash method.
Each branch router was provisioned with two IPSec/GRE tunnels (primary and secondary) back to two
different head-ends. EIGRP was used as the routing protocol to distribute routes from the head-ends to
the branches. Note that the testing was conducted with a fully summarized network configuration.

EDCS-202049 2-21
Some performance tests use the IMIX standard for specification of packet sizes. Typically these tests
then continually send streams of the specified packet sizes to a device under test to evaluate its
performance.
In this particular scalability test, instead of streams of particular packet sizes, realistic traffic flows were
established using the NetIQ Chariot testing tool. The mix of traffic was approximately 35 percent UDP
and 65 percent TCP.
A comparison of IMIX and the traffic profile used during this evaluation is shown in Table 2-4.
Table 2-4 Comparison of IMIX and Traffic Profile
Cisco Scalability Test IMIX

G.729 RTP (64-byte packets)—50 pps 40-byte packets—7 parts
DNS (100-byte packets)—4 flows 576-byte packets—4 parts
FTP (1400-byte packets)—1 flow 1500-byte packets—1 part
Although not matched one-for-one with the IMIX standard, the traffic profile used in this evaluation is
believed to yield conservative performance data.
This is due to two factors:
• The Chariot streams simulate realistic traffic flows instead of packet blasting.
• This profile contains a significant percentage of small packets, a somewhat more aggressive profile
than IMIX.
The evaluation was then performed by increasing traffic rates using this profile to find the throughput
points on each product where the CPU utilization reached the defined limits (50 percent for head-ends,
65 percent for branch routers). Additionally, zero packet loss was permitted.
Individual product throughput performance data is presented in “Cisco VPN Routers for Head-ends”
section on page 2-26 for head-end products and “Cisco VPN Routers for Branch Sites” section on
page 2-28 for branch end products.
In addition to throughput testing, failover testing was also conducted. Please see to “Network
Performance/Convergence” section on page 2-29 for more information on the failover test scenario.
All scalability testing for this publication was performed using IPSec Tunnel Mode; the throughput
results might differ in Transport Mode.
Hardware-Accelerated Encryption
The scalability testing performed as part of the VPN solution development indicates a strong need for
hardware-accelerated encryption to achieve predictable performance results. For head-end devices, all
throughput results presented in this design guide and the recommended architecture assume that
hardware-acceleration is implemented.
For branch-end devices, both software-based encryption and hardware-accelerated encryption were
evaluated. Throughput performance was significantly increased (up to 80 percent) with the addition of
hardware-accelerated encryption.
For these reasons, Cisco strongly recommends hardware acceleration in all devices performing
encryption. This is especially true if:
• Triple DES encryption is being implemented.
• Significant data throughput requirements exist.

2-22 EDCS-202049
• Multi-service applications, such as IP Telephony, are to be run over the VPN.

Cisco has different names for the acceleration modules of the Cisco 7200 and Cisco 7100 families. The
Integrated Services Adapter (ISA) be used on the Cisco 7100 or Cisco 7200. The Integrated Services
Modules (ISM) can be used on the Cisco 7100. They offer comparable performance. Multiple cards (dual
ISA on a Cisco 7200, ISM+ISA on Cisco 7100) can be used to increase encryption throughput. Although
not yet evaluated in scalability testing, the VPN Acceleration Module (VAM) is another
high-performance VPN encryption option.
For branch access routers, hardware-acceleration components are typically Advanced Integration
Modules (AIM).
See “Cisco VPN Routers for Head-ends” section on page 2-26 and “Cisco VPN Routers for Branch
Sites” section on page 2-28 for more detailed performance data that supports this recommendation.
Head-end Devices
The head-end devices are responsible for:
• Originating/terminating IPSec encapsulated GRE tunnels from the branch sites
• Running routing protocol inside GRE tunnels to advertise internal routes to branches
• Providing resiliency to eliminate the possibility of a single point of failure
The next sections identify factors to take into account in sizing the head-end (or sites). Specific sections
include:
• Sizing the Head-end
• Cisco VPN Routers for Head-ends
• Other Cisco Products
Sizing the Head-end

Sizing the head-end correctly before choosing the devices to deploy ensures that the overall network can
support the intended (and possibly future) traffic profiles to be run over the VPN.
Two critical factors must be considered when sizing the head-end:
• How many branch offices must be connected to the head-end? This provides the number of primary
tunnels requiring aggregation.
• What is the expected traffic profile, including the average packets-per-second (pps) and
bits-per-second (bps) throughput rates for each branch office? This provides the aggregated data
throughput required across the VPN.
These factors can limit sizing the head-end and must be considered together. The decision flow shown
below in Figure 2-8 should be applied to size the head-end.

EDCS-202049 2-23
Figure 2-8 Head-end Sizing Decision Flow
Calculate Head-
end Devices
How many
based on Number
branches?
of Tunnels
C(t)
Which
is greater
?
Calculate Head-
Consider Head- end Devices
Throughput end Product based on Branch
per branch? Options Throughput
C(a)
Other Adjust according

Preliminary to other known Final
Factors
Estimate ? factors Estimate
74178
Note This design assumes a level of resiliency at the head-end to handle a failover scenario.
Scalability testing was conducted up to and including 240 tunnels per head-end. The Cisco VPN Router
products evaluated as head-end devices are often capable of aggregating more than 240 tunnels. Ultimate
peer scalability is dependent on numerous factors including resiliency design, routing, and other services
running on the device.
Using a routing protocol (such as EIGRP as in this design) also affects the number of peer devices that
can be effectively aggregated to a particular head-end. To date, support for 240 peers has been verified
in scalability testing. Again, more peers per head-end are possible, but planning using an initial limit of
240 is recommended, as this configuration has been verified. A future version of this publication will
contain scalability performance data for higher than 240 peers.
Based on the number of branch offices, the required number of head-end devices, C(t), can be sized with
the following algorithm:
N = Total number of branch offices
T = Total number of tunnels = N x 2 (for primary and secondary tunnels)
C(t) = (T / 240) rounded up to next full integer + 1 (for resiliency)
For example, an enterprise with 950 branch offices would require nine head-end devices for a resilient
design, as follows:
N = 950
T = 1900
C(t) = 1900/240 rounded up + 1 = 9
The next step is to obtain traffic profile data that indicates expected average throughput (pps and bps)
for each branch office and head-end device.

2-24 EDCS-202049
The aggregate throughput is then calculated by adding up all of the throughput estimates for all branch
offices.
Next consider the available head-end devices and the maximum throughput supported by each. The
Cisco 7140 and Cisco 7200VXR routers are the preferred platforms for use as IPSec VPN head-end
devices. Each of these routers has a range of options for interfaces as well as the ability to configure
hardware-accelerated encryption. See “Cisco VPN Routers for Head-ends” section on page 2-26 for
more details on product selection and throughput performance.
Now divide the aggregate throughput requirements by the throughput value for each respective platform
(please refer the values provided in Table 2-5 discussed in “Cisco VPN Routers for Head-ends” section
on page 2-26). This will provide the number of head-end devices required, based on aggregate
throughput:
A = Sum of throughput estimates for each branch office (i.e. the aggregate)
H = Single head-end device throughput
C(a) = A/H, rounded up to nearest full integer, + 1 for resiliency
For example, an enterprise with 300 branch offices, each having throughput requirements of 500 Kbps
would require six head-end devices for a resilient design, as follows:
A = 300 branches @ 500 Kbps = 300 x 0.5 Mbps = 150 Mbps
H = 30 Mbps (for Cisco 7140 router)
C(a) = 150/30 (rounded to next nearest integer) + 1 = 6
Compare the number of head-end devices calculated based on number of tunnels, C(t), to the number
based on aggregate throughput, C(a). The greater of the two numbers is the required number of head-end
devices to support the design outlined in this publication.
As the number of tunnels increases there is a corresponding increase in CPU utilization. This means that
a design that has a uniformly distributed traffic load from branch offices across many tunnels will require
more CPU than a design where the majority of traffic load is generated from a subset of the total tunnels
being aggregated.
In addition to the two critical factors identified above, the following factors must also be considered at
this point:
1. Given the current network topology and traffic profile, what is the current CPU utilization on each
distribution router, and how many branch offices are connected to each distribution router?
This provides a baseline of expected CPU utilization levels. The combination of crypto/IPSec and
GRE will add additional overhead to each distribution router.
2. What are the aggregate WAN sizes for each respective branch?
How the aggregate WAN speed is subdivided into a number of tunnels will affect the overall number
of tunnels that can be supported in this design. As discussed previously, as the number of tunnels
increases, there is a corresponding decrease in throughput (or an increase in CPU utilization).
3. What other applications/protocols does the customer intend to run across the VPN?
Multi-protocol implementations perform differently in a Cisco IOS environment compared to
unicast-IP implementations. In the scalability testing performed to date, multi-protocols have not
been comprehensively evaluated.
The end result is that the number of head-end devices might need to be adjusted upward after these
additional factors are considered.

EDCS-202049 2-25
In the design presented in this publication, head-end device CPU utilization does not exceed 50 percent.
This conservative recommendation ensures that the device has enough performance left over to deal with
various events that take place during the course of normal network operations. Typical events include
network reconvergence in the event of a failure, rekeying IPSec SAs, and bursts of traffic seen in a
normal operating network.
After initial deployment and testing, it might be possible to run head-end devices at CPU utilization
levels higher than 50 percent (60 to 65 percent for example). However, this publication conservatively
recommends staying at or below 50 percent—as a result the throughput results presented where chosen
at the 50 percent level.
Cisco VPN Routers for Head-ends

Cisco has an array of VPN routers suitable for head-end deployments. These include the Cisco 7100,
Cisco 7200, and Cisco 3600 Series routers. Specific platforms were selected from within each product
family for evaluation.
All products were configured with hardware-accelerated encryption enabled. Each product supports
several hardware-accelerated encryption options. For example, both the Cisco 7100 and Cisco 7200
Series can be configured with one or two ISA/ISM cards or the newer VAM. The Cisco 3600 Series can
be configured with different AIM performance levels, including Base (AIM-BP), Medium (AIM-MP) or
High (AIM-HP) depending on platform.
The configurations selected for scalability testing, along with the throughput thresholds attained (at 50
to 55 percent CPU utilization and 240 tunnels configured) are shown Table 2-5. Due to test limitations,
traffic was generated over a subset of the configured tunnels in this particular scalability test.
Table 2-5 Head-end Products Throughput
Hardware
Acceleration Maximum Scalability Traffic Mix
Head-end Router Platform Option Performance1 Performance2
Cisco 7200VXR NPE-400 SA-ISA (1) 90 Mbps 40.0 Mbps
VAM 140 Mbps To be added in future
publication version
Cisco 7200VXR NPE-300 SA-ISA (1) 90 Mbps 30.0 Mbps
publication version
Cisco 7140 SA-ISM (1) 90 Mbps 30.0 Mbps
publication version
Cisco 3660 AIM-HP (1) See branch results in See branch results in
Table 2-7 Table 2-7.
2. Scalability traffic mix evaluation performed with mixed packet sizes, 55 percent CPU utilization, and up to 240 IPSec/GRE
tunnels.
In this version of the publication and corresponding scalability tests, the Cisco 3600 Series was evaluated
only as a branch device. However, the Cisco 3600 Series can also be implemented as a head-end device.
Scalability testing is currently underway for this configuration. See “Cisco VPN Routers for Branch
Sites” section on page 2-28 for more information on the Cisco 3600 Series as a branch device.

2-26 EDCS-202049
New Cisco Head-end Products

performed with the design presented in this publication. Table 2-6 shows the latest Cisco VPN router
products targeted for use as head-end devices, along with their measured maximum performance.
Table 2-6 Latest Cisco VPN Head-end Router Products
Head-end Router Hardware Acceleration

Platform Option Maximum Performance1
Cisco 7400 VAM Up to 120 Mbps
Cisco 3745 AIM-EP Up to 40 Mbps
1. Maximum performance evaluated with 1400-byte packet size, full CPU utilization, and
single IPSec/GRE tunnel.
Other Cisco Products

Several other Cisco products support IPSec VPN tunnel termination in a head-end environment,
including the Cisco VPN3000 Concentrator and the Cisco PIX Firewall Series products. These platforms
were not part of the scalability testing and therefore are not fully discussed.
See the following links for more product information on the Cisco VPN3000 and Cisco PIX Series:
• http://www.cisco.com/warp/public/cc/pd/hb/vp3000/
• http://www.cisco.com/warp/public/cc/pd/fw/sqfw500/
Branch Site Devices

The branch site devices are responsible for:
• Originating/terminating IPSec encapsulated GRE tunnels from the head-end
• Running a routing protocol inside of the GRE tunnels to advertise internal routes
The next sections identify factors to take into account when sizing the branch sites. Specific sections
include:
• Sizing the Branch Site
• Cisco VPN Routers for Branch Sites
• Other Cisco Products
Sizing the Branch Site

The most important factor to consider when choosing a product for the branch office is expected traffic
throughput.
Secondary factors that should be considered include:
• Other features/functionality that the branch router will be providing, such as WAN access, IP
Telephony, DHCP, or Cisco IOS firewall.

EDCS-202049 2-27
• Differences in the range of features that branch devices can accommodate. For example, the Cisco
3660 supports six modular slots and various WAN adapters, while the Cisco 2600 series supports
only two slots.
While the number of IPSec tunnels will not play as large a role in the branch device sizing, each branch
site router must be able to terminate at least two IPSec-encapsulated GRE tunnels (primary and
secondary).
The principal concern is the amount of traffic throughput along with the corresponding CPU utilization.
In the design presented in this publication, branch device CPU utilization does not exceed 65 percent.
This conservative recommendation ensures that the device has enough performance left over to deal with
various events that take place during the course of normal network operations. The CPU utilization on a
branch site may run slightly higher than a head-end router due to minimal routing convergence duties
associated with branch routers.
After initial deployment and testing, it might be possible to run branch devices at CPU utilization levels
higher than 65 percent. However, this publication conservatively recommends staying at or below 65
percent, and therefore the throughput results presented where chosen at the 65 percent level.
Cisco VPN Routers for Branch Sites

Cisco has a line of VPN routers suitable for branch site deployments. These include the Cisco 3600,
Cisco 2600, Cisco 1700, and Cisco 800 Series routers. All branch devices except the Cisco 800 Series
support hardware-accelerated encryption.
Specific platforms were selected from within each product family for evaluation. All products were
evaluated with both hardware-accelerated encryption enabled as well as software-based encryption.
Throughput results (at approximately 65 percent CPU utilization) are summarized in Table 2-7.
Table 2-7 Branch Site Device Throughput
Scalability Traffic Mix Scalability Traffic Mix

Hardware (HW) Maximum Performance with HW Performance with SW
Branch Router Platform Acceleration Option Performance1 Encryption2 Encryption3
Cisco 3660 AIM-HP 38.1 Mbps 16.0 Mbps 2.4 Mbps
Cisco 3640 AIM-MP 14.7 Mbps 3.5 Mbps 900 Kbps
Cisco 3620 AIM-MP 8.0 Mbps 1.8 Mbps 480 Kbps
Cisco 2651 AIM-BP 14.0 Mbps 2.8 Mbps 960 Kbps
Cisco 1750 VPN Module 3.0 Mbps 2.6 Mbps 560 Kbps
Cisco 806 N/A 384 Kbps N/A Not evaluated
Cisco 805 N/A N/A N/A 100 Kbps
2. Scalability traffic mix evaluation performed with mixed packet sizes, 65 percent CPU utilization, and two IPSec/GRE tunnels.
3. Refer to the footnote above for “Scalability Traffic Mix Performance with HW Encryption.”

2-28 EDCS-202049
New Cisco Branch Site Products

performed with the design presented in this publication. Table 2-6 shows the latest Cisco VPN Router
products targeted for use as branch devices, along with their measured maximum performance.
Table 2-8 Latest Cisco VPN Branch Site Router Products
Head-end Router Hardware Acceleration

Platform Option Maximum Performance1
Cisco 1760 VPN Module Up to 10 Mbps
1. Maximum performance evaluated with 1400-byte packet size, full CPU utilization, and
single IPSec/GRE tunnel.
Other Cisco Products

Several other Cisco products support IPSec VPN tunnel termination in a branch site termination
environment. These include the Cisco VPN 3002 Concentrator, Cisco PIX 501 and Cisco PIX 506
firewalls. These platforms were not part of the scalability testing and are not fully discussed in this
publication.
See the following links for more product information on the Cisco VPN 3000 and Cisco PIX Series:
• http://www.cisco.com/warp/public/cc/pd/hb/vp3000/
• http://www.cisco.com/warp/public/cc/pd/fw/sqfw500/
Network Performance/Convergence
Each network deployment can have different convergence time requirements. The design principles in
this guide were used to perform a scalability test with 240 branch offices aggregated to two head-end
devices. Standard timer values were configured for the routing protocol being used. Traffic load was
established between the 240 branches and two head-ends. Aggregation to three head-end devices was
also evaluated for comparison purposes.
The test was performed by powering off one of the head-end devices to simulate a complete failure. The
120 affected branches successfully failed over to the surviving head-end. In this test, the network fully
converged after 22 seconds.
The same test was then performed with 240 branch offices aggregated to three head-end devices. All 80
branches from the failed head-end successfully failed over to the two surviving head-ends. In this test,
the network fully converged after 22 seconds.
Convergence times were found to be well within the timeframe to maintain TCP connections.
In both scenarios, the failed head-end device was then powered back on, resulting in the network
re-converging in less than two seconds. The IPSec tunnels re-established a few at a time as their
corresponding SAs were renegotiated. The last IPSec tunnels re-established after 1-1/2 to two minutes.
During this recovery and SA negotiation period, network connectivity is already established.

EDCS-202049 2-29
Additional Considerations for Latency-Sensitive Traffic
Software Releases Evaluated

The software releases shown in Table 2-9 were used in scalability testing:
Table 2-9 Software Releases Evaluated
Product Type Software Release

Cisco Head-end Routers (Cisco 7140, Cisco Cisco IOS 12.1(9)E (with Triple DES IPSec
7200) support)
Cisco Branch Office Routers (Cisco 1750, Cisco Cisco IOS 12.2(8)T (with Triple DES IPSec
26xx, Cisco 36xx) support)1
Cisco Catalyst Switches (Cisco 2948G, Cisco Cisco CatOS 5.5
6x00)
1. Cisco IOS 12.2(8)T is the current minimum recommendation for branch products. Cisco IOS 12.2(3.5)T was the actual
software evaluated for this publication, however, an interim release and is not available for external deployment.
Note Several Cisco IOS images exist with each configured with various levels of encryption technology. There
are certain restrictions and laws governing the use and export of encryption technology.
With the Cisco IOS images referenced in Table 2-9, all VPN features may be enabled, including Triple
DES. Before selecting Cisco IOS software, perform the appropriate research through
http://www.cisco.com and consult with technical support representative. Be aware of any issues in
specific levels of code that can affect other configured features.

VPNs are often positioned as traditional WAN replacements, since they offer the same interconnectivity
between a central campus and branch offices, often with greater flexibility and lower cost. As a result,
customers expect the same level of services offered by a WAN, including the ability to run
latency-sensitive applications, such as IP Telephony and video, across the VPN.
End-to-end QoS is required to achieve acceptable quality, including low latency and jitter. Provisioning
and deploying an IPSec-based VPN with QoS enabled is currently under study and scalability testing.
Some preliminary findings are important to consider when deploying a QoS enabled VPN. These are
highlighted in the following subsequent sections:
• Quality of Service (QoS)
• Pre-classification of Traffic
• Lower Link Speeds
• Hardware-Accelerated versus Software-Based Encryption
• Compressed RTP Not Supported by IPSec
• Additional Service Provider Considerations

2-30 EDCS-202049
Quality of Service (QoS)

Quality of Service (QoS) is an issue when significant levels of voice and video traffic is added to network
with heavy data traffic. Mission-critical and time-sensitive traffic—such as voice— must receive higher
QoS guarantees than less time-sensitive traffic such as file transfers and emails.
Increasing bandwidth to solve this problem involves higher cost. A QoS-based solution offers the
potential for optimized and differentiated use of existing bandwidth.
QoS enables assignment of different qualities to different data streams. Cisco provides a number of
comprehensive end-to-end QoS mechanisms to improve voice quality and to optimally utilize WAN
bandwidth. Examples of these mechanisms are:
• Packet classification and usage policies applied at the edge of the network, such as Policy Based
Routing (PBR) and Committed Access Rate (CAR).
• End-to-end queuing mechanisms, such as Low Latency Queuing (LLQ). Because voice is
susceptible to increased latency and jitter on slow speed links, LFI may also be used to reduce delay
and jitter by breaking up large datagrams and interleaving low-delay traffic with the resulting
smaller packets
• Scheduling mechanisms to optimize bandwidth utilization on output links, such as Traffic Shaping
QoS is beyond the scope of this publication, but will be included in a future version after scalability
testing is completed.
Pre-classification of Traffic
Starting with Cisco IOS 12.2(2)T, a new pre-classification feature provides the prerequisite traffic
classification needed to provide QoS across the VPN.
Pre-classification is not simply copying of the Type of Service (ToS) bits to the front of the encrypted
IPSec packet. Pre-classification preserves Cisco IOS QoS functionality and must be used whenever a
VPN hardware-accelerated encryption card and Cisco IOS QoS are needed on the same Cisco router. It
additionally provides the ability for the Cisco VPN router to provide WAN-edge QoS, based on
encrypted elements—such as User Datagram Protocol (UDP) port or source address/destination address
(SA/DA).
Pre-classification is currently implemented for the Cisco 2600, Cisco 3600, Cisco 7100 and Cisco 7200
Series VPN routers. This feature was not tested in the initial scalability tests conducted for this
publication.
For additional information on why and how to implement pre-classification, see the following link:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/dtqosvpn.htm
Pre-classification is beyond the scope of this publication, but will be included in a future version after
scalability testing is completed.
Lower Link Speeds

Link speeds can be provisioned for branch sites at varying rates, from relatively low rates to very high
rates depending on throughput requirements. For VPNs where the primary traffic is data, all link speeds
readily support the requirements in this publication.

EDCS-202049 2-31
When extending a VPN to support multi-service applications, such as IP Telephony and video, latency
must be considered. On interfaces with lower link speeds, link fragmentation and interleaving (LFI) is
required to minimize serialization delay incurred by transmitting large packets (such as 1400-byte
packets) in front of smaller IP Telephony packets (such as 64-byte packets).
If you anticipate running latency-sensitive applications over the VPN, plan to implement QoS features
that minimize delay.
Hardware-Accelerated versus Software-Based Encryption

In addition to the recommendations outlined in “Hardware-Accelerated Encryption” section on
page 2-22, other considerations favor implementing hardware-accelerated encryption in platforms that
will support latency sensitive applications. For example, with software-based encryption it is not
possible to achieve acceptable levels of latency and jitter that are predictable. For example, large data
packets can overwhelm the encryption software and lead to unacceptable delays in receiving IP
Telephony packets. Hardware-accelerated encryption adds up to 80 percent more encryption processing
capacity to prevent this from occurring.
Compressed RTP Not Supported by IPSec

Header compression provides a very valuable service to latency sensitive protocols such as IP Telephony.
When using Compressed Real Time Protocol (cRTP) to transport IP Telephony, packet redundancy from
the Layer 3 and Layer 4 headers is removed from the stream, resulting in a lower traffic burden.
Due to the nature of IPSec as outlined in the IETF standard, use of cRTP is not possible. This is not a
Cisco IOS limitation, but an inherent incompatibility between the two protocols. Alternative protocols
to cRTP to achieve header compression are being investigated for future implementation.
Currently the only workaround is to provision the links so that sufficient bandwidth exists to transport
the whole packet without header compression.
Additional Service Provider Considerations

VPNs inherently rely on one or more SPs to provide Internet service to the head-end and branch offices
in order to deploy the network. It is important to note that some service providers may or may not honor
classifications of delay-sensitive traffic—referred to as type of service (ToS)—and can therefore
experience unacceptable levels of delay or jitter on voice traffic.
Whenever possible, SLAs with SPs should be put into place. SLAs provide a stronger guarantee that
delay-sensitive traffic will be handled in a QoS-type manner across the ISP network. This enables the
enterprise to achieve end-to-end QoS for this type of traffic.
Complications can also arise when multiple SPs are involved. For example, one SP might not honor the
ToS classification bits from another SP. Additional latency can also be introduced by having
latency-sensitive traffic needing to traverse multiple SP backbones.
Furthermore, when a small office subscribes to cable or DSL Internet service provisioned for residential
customers, problems can be encountered. Certain traffic types might be blocked prohibiting the effective
deployment of a VPN (such as IP Telephony signaling protocols). Therefore it is strongly recommended
that small offices subscribe to business-level cable or DSL service.

2-32 EDCS-202049
Enterprise Site-to-Site VPN Case Study

The key objective of this case study is to provide a reference example for a site-to-site VPN design. It
provides an example of how these design principles can be applied in a real-world implementation.
This case study assumes that all of the design considerations in “Solution Design Recommendations”
section on page 2-6 and “Solution Component Recommendations” section on page 2-21 have been
addressed and that best practice design recommendations are adopted by the customer.
The case study also assumes that the Cisco IOS software levels listed in “Software Releases Evaluated”
section on page 2-30 are acceptable to the customer.
The details of the SP backbone and WAN connectivity are not addressed in the case study because the
focus is with VPN deployment on the enterprise customer side.
Enterprise Organization Overview

Moose Widgets has been developing products at their Portland, Oregon headquarters (HQ) for several
years. In addition, Moose Widgets has a single distribution center and 20 retail outlets across the United
States (US). Currently Moose Widgets utilizes a traditional frame relay (FR) WAN service to connect its
HQ network to its distribution center network. There is currently no connectivity to retail outlets, with
the exception of a few outlets that, use personal computers (PCs) to dial-up to the corporate HQ. The
current network topology is illustrated in Figure 2-9.
Figure 2-9 Moose Widgets Case Study Current Topology
Distribution Ctr
Seattle, WA
Moose Widgets HQ
Portland, OR Frame
relay Retail outlets
(20)
Corporate PSTN
network
74180
Dialup

EDCS-202049 2-33
Moose Widgets recently acquired two companies, one in San Jose, California and the other in Great
Falls, Montana. Moose Widgets wants to connect its newly acquired companies and its retail outlets to
its corporate network as an intranet. In addition, Moose Widgets plans to expand its retail outlets (from
its current level of 20 to between 40 and 50) over the next year. Further, Moose recognizes that it needs
additional distribution centers on the east and west coasts of the US to handle this expansion.
As part of a corporate initiative, Moose Widgets is implementing a centralized inventory tracking system
to more cost-effectively manage inventory in its growing distribution centers and retail outlets. The
existing dial-in access does not provide adequate bandwidth to support the new applications. Moose
Widgets is also concerned about an anticipated escalation of dial-in charges as each retail outlet will
increasingly rely on corporate resources. As a result, Moose Widgets is looking to transition to a
dedicated connection for each of its retail outlets using the Internet and VPN technology.
Moose Widgets is concerned about the costs of adding the connections. It is also concerned about the
ability to quickly get retail outlets up and running. Moose Widgets management indicated that it is
primarily concerned about data traffic today, but there is some degree of interest in adding voice services
in the future.
Moose Widgets estimates its traffic requirements for the different site locations as shown in Table 2-10.
Table 2-10 Moose Widgets Case Study Traffic Profile
Location Estimated Traffic

Distribution Center (one today, 1 Mbps
potentially three in the future)
San Jose 4 Mbps
Great Falls 4 Mbps
Retail Outlets (up to 50) 50Kbps (typical); 40 outlets
200Kbps (larger); 10 outlets
Total 15Mbps
Moose Widgets approached Cisco to determine how a Virtual Private Network might meet its
requirements.

2-34 EDCS-202049
Design Considerations
The design adopted for Moose Widgets provides for deployment of a site-to-site IPSec VPN, with the
Moose Widgets corporate HQ serving as the head-end. All other locations are treated as branch sites.
This allows a branch office to subscribe to a local ISP, get authenticated, and remain inside the corporate
intranet.
At the same time, end-to-end encryption is enabled using IPSec tunneling. Switching to VPN offers
Moose Widgets significant cost savings over dial-up solutions and the ability to outsource to a SP that
has VPN service as a core competency, resulting in better cost-efficiency and scalability.
The initial goal is to provide VPN connectivity to onsite employees.
Following the design practice outlined in “Solution Design Recommendations” section on page 2-6 and
“Solution Component Recommendations” section on page 2-21, there are four main design steps to
perform:
• Preliminary Design Considerations
• Sizing the Case Study Head-end
• Sizing the Case Study Branch Sites
• Tunnel Aggregation and Load Distribution
Preliminary Design Considerations

The design adopted is straightforward and flexible. As new retail locations enter service, Moose Widgets
can purchase Internet connectivity from the local ISP, deploy a Cisco VPN Router at the branch site,
configure the IPSec tunnels to the head-end devices at the corporate headquarters, and enable secure
intranet access in a short amount of time.

EDCS-202049 2-35
Using the questions from “General Design Considerations”, Table 2-11 summarizes the preliminary
design considerations.
Table 2-11 Preliminary Design Considerations Summary
Question Answer Comments

What applications are expected Data Interested in future voice
to run over the VPN? services
Is multi-protocol support Yes, using EIGRP for routing is GRE tunnels will enable
required? desired. multi-protocol traffic transport.
How many branches will be 55 sites
aggregated to the head-end?
What is the expected traffic See Table 2-10
throughput to/from branch
offices?
What are the expectations for Resiliency is required 1 primary, 1 backup tunnel
resiliency?
What encryption level is Triple DES
required?
What type of IKE authentication Pre-shared keys is selected due Migration to digital certificates
method will be used? to relatively small number of should be considered if number
sites to manage. of branches increases beyond 50
in the future.
What other services will be run None
on the branch VPN routers?
Sizing the Case Study Head-end

While the traffic loads involved are not expected to exceed the recommended capacity of a single
head-end device, Moose Widgets indicated it desires built-in resiliency at the central location. To meet
this requirement, the tunnels from the remote ends are allocated to each of the head-end devices to
balance the traffic load. To provide the service resiliency needed, secondary tunnels are configured and
allocated so that in the event of a head-end failure, traffic is transitioned over to the partner head-end
device.
Applying the sizing algorithm defined in “Sizing the Head-end” section on page 2-23 presented earlier,
the calculation of head-end sizing based on number of tunnels is as follows:
N = 55
T = N x 2 = 110
C(t) = (T / 240) rounded up + 1 = 110/240 rounded +1 = 1 + 1 = 2 head-ends
Next, apply the sizing algorithm defined in “Sizing the Head-end” section on page 2-23 and using the
throughput estimates from Table 2-10, the calculation of head-end sizing based on branch traffic
throughput is as follows:
A = (3*(1 Mbps)+4 Mbps+4 Mbps+40*(50kbps)+10*(200kbps)) = 15 Mbps
H = 40 Mbps (for Cisco 7206VXR NPE-400)
C(a) = A/H, rounded up + 1 = 15/40 rounded up + 1 = 1+1 = 2 head-ends

2-36 EDCS-202049
Comparing the number of head-end devices calculated based on number of tunnels, C(t), to the number
based on aggregate throughput, C(a), the outcomes match. Therefore it is appropriate to deploy two
head-end devices.
Presented with the head-end product options, the customer selects to deploy two Cisco 7206VXR
NPE-400 routers, each equipped with an ISA hardware encryption adapter.
Sizing the Case Study Branch Sites

The primary consideration for sizing of branch office sites is expected traffic throughput. Accordingly,
starting with Table 2-10, and applying the concepts presented in “Sizing the Branch Site” section on
page 2-27 presented earlier, the branch products selected are summarized in the Table 2-12.
Table 2-12 Branch Site Product Selection Summary
Branch Office Platform

Location Estimated Throughput Selected
Distribution Centers 1 Mbps Cisco 2651
San Jose 4 Mbps Cisco 3660
Great Falls 4 Mbps Cisco 3660
Retail Outlets (typical) 50 Kbps Cisco 1750
Retail Outlets (larger) 200 Kbps Cisco 2611
At each of the acquired company locations, a Cisco 3660 VPN router is deployed with high performance
hardware-accelerated encryption (AIM-HP). The choice of the Cisco 3660 platform is based on the
assumption that the acquired companies are large offices with a substantial number of employees.
At each of the distribution centers, a Cisco 2651 Series VPN router is deployed with base performance
hardware-accelerated encryption (AIM-BP).
Finally, at each of the retail locations, the Cisco 2611 is recommended for the larger retail outlets and
the Cisco 1750 for smaller retail outlets.
Tunnel Aggregation and Load Distribution

Given 55 branch sites, the total number of tunnels to be aggregated 110 (including primary and
secondary tunnels). The first head-end device is allocated 27 primary and 28 backup tunnels, while the
second head-end device is allocated 28 primary and 27 backup tunnels.

EDCS-202049 2-37
Network Layout
An example network topology is shown in Figure 2-10.
Figure 2-10 Moose Widgets Case Study VPN Topology
Moose Widgets HQ Distribution centers

Portland, RO (3)
Cisco 2651 Cisco 2651
Retail outlets
(40-50)
Cisco
7206VXR Cisco
NPE-400 2611
Internet
Cisco
1750
Corporate
network Cisco Cisco
3660 3660
Widgetvision Wilderness Labs
74181
Technologies Great Falls, MT
San Jose, CA

2-38 EDCS-202049
Configuration Discussion
The configuration issues defined in this chapter are specific to VPN implementation. It is assumed that
the reader is familiar with standard Cisco configuration practices at the Command Line Interface (CLI)
level.
All example configurations shown are for IPSec in Tunnel Mode.
There are a number of configuration items that must be addressed to implement IPSec functionality. The
general steps are as follows.
Step 1 Configure IKE policy—See “IKE Policy Configuration” section on page 2-39
Step 2 Configure IPSec Transform and Protocol—See “IPSec Transform and Protocol Configuration” section
on page 2-40
Step 3 Create Access Lists for Encryption—See “Access List Configuration for Encryption” section on
page 2-40
Step 4 Configure Crypto Map—See “Crypto Map Configuration” section on page 2-41
Step 5 Apply Crypto Map—See “Applying Crypto Maps” section on page 2-41
The sections which follow cover each of these steps in more detail. In addition, the following link offers
additional information:
http://www.cisco.com/cgi-bin/Support/PSP/psp_view.pl?p=Internetworking:IPSec
IKE Policy Configuration

There must be at least one matching IKE policy between two potential IPSec peers. The example
configuration below shows a policy using pre-shared keys with Triple DES as the encryption transform.
There is a default IKE policy that contains the default values for the transform, hash method,
Diffie-Hellman group, authentication and lifetime parameters. This is the lowest priority IKE policy.
When using pre-shared keys, Cisco recommends that wildcard keys be avoided. Instead, the example
shows two keys configured for separate IPSec peers. The keys should be carefully chosen. Here,
bigsecret is used only as an example. The use of keys containing alpha-numeric and punctuation
characters is recommended.
Head-end Router
ip address 192.168.251.1 255.255.255.0
!
crypto isakmp policy 1
encr 3des
authentication pre-share
crypto isakmp key bigsecret address 192.168.161.2

EDCS-202049 2-39
Branch Site Router

interface s0/0
ip address 192.168.161.2 255.255.255.0
!
encr 3des
These defaults and more information can be found at:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_r/fipsencr/srfike
.htm#xtocid17729
IPSec Transform and Protocol Configuration

The transform set must match on the two IPSec peers. The transform set names are only locally
significant. However the encryption transform, hash method and the particular protocols used (ESP or
AH) must match. You may also configure data compression here but it is not recommended on peers with
high speed links. There can be multiple transform sets for use between different peers.
Head-end Router
ip address 192.168.251.1 255.255.255.0
!
crypto ipsec transform-set vpn-test esp-3des esp-sha-hmac
Branch Site Router

interface s0/0
ip address 192.168.161.2 255.255.255.0
!
More information can be found at:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_r/fipsencr/srfips
ec.htm#xtocid105784
Access List Configuration for Encryption

The access list entries defining the traffic to be encrypted must mirror each other on the IPSec peers. If
access list entries include ranges of ports, then a mirror image of those same ranges must be included on
the remote peer access lists. The addresses specified in these access lists are independent of the addresses
used by the IPSec peers. In this example, GRE is specified on both the source and destination parts of
the access list. All traffic encapsulated in the GRE packets will be protected.
Head-end Router
ip address 192.168.251.1 255.255.255.0
!
ip access-list extended vpn-static1 permit gre host 192.168.251.1 host 192.168.161.2

2-40 EDCS-202049
Branch Site Router

interface s0/0
ip address 192.168.161.2 255.255.255.0
!
ip access-list extended vpn-static2 permit gre host 192.168.185.2 host 192.168.251.1
Crypto Map Configuration

The crypto map entry ties together the IPSec peers, the transform set used and the access list used to
define the traffic to be encrypted. The crypto map entries are evaluated sequentially.
In the example below, the crypto map name static-map and crypto map numbers (such as 1 and 20) are
only locally significant. The first statement sets the IP address used by this peer to identify itself to other
IPSec peers in this crypto map. This address must match the set peer statement in the remote IPSec peer
crypto map entries. This address also needs to match the address used with any preshared keys the remote
peers might have configured. The IPSec mode defaults to tunnel mode.
Head-end Router
ip address 192.168.251.1 255.255.255.0
!
crypto map static-map local-address FastEthernet1/0
crypto map static-map 1 ipsec-isakmp
set peer 192.168.161.2
set transform-set vpn-test
match address vpn-static1
Branch Site Router

interface s0/0
ip address 192.168.161.2 255.255.255.0
!
crypto map static-map local-address Serial0/0
set peer 192.168.251.1
A more complete description can be found at:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_r/fipsencr/srfips
ec.htm#xtocid105785
Applying Crypto Maps

The crypto maps must be applied to the interfaces, both the physical interface and the logical interfaces,
such as the GRE tunnel interfaces.
Head-end Router
ip address 192.168.251.1 255.255.255.0
!
interface Tunnel1
ip address 10.62.1.193 255.255.255.252
tunnel source 192.168.251.1

EDCS-202049 2-41

!
ip address 192.168.251.1 255.255.255.0
Branch Site Router

interface s0/0
ip address 192.168.161.2 255.255.255.0
!
interface Tunnel1
ip address 10.63.25.198 255.255.255.252
!
interface Serial0/0
bandwidth 1536
ip address 192.168.161.2 255.255.255.0
Dynamic Crypto Maps

Rather than pre-define all the IPSec peers, another option is to create dynamic crypto maps. Dynamic
crypto maps allow an IPSec connection between two peers when the central site peer does not have all
the configuration necessary to complete an IPSec negotiation with a remote peer. This situation can
occur when the remote peer has its IP address dynamically assigned—as in the case of a residential-class
ISP connection like Cable or DSL. Since the remote peer’s IP address might be unknown, it cannot be
preprogrammed into the central site device.
IKE is required for authentication with dynamic crypto maps. The IKE authentication will complete
based on an identity other than the remote peer’s IP address, such as the peer's fully qualified domain
name (FQDN). The information from the IKE session will then be used to complete the missing
information in the dynamic crypto map.
Because the IP address of the peer is unknown until the IKE session is negotiated, GRE tunnels cannot
be configured and cannot be used. This also prevents running a routing protocol. Resiliency can be
accomplished with use of the relatively new Cisco IOS features Dead Peer Detection (DPD) and Reverse
Route Injection.
When dynamic crypto maps are used, an IPSec peer must accept connections from any IP address. For
this reason the use of pre-shared keys is not recommended with dynamic crypto maps.
Note Dynamic crypto maps have not been evaluated in scalability tests and are not covered further in this
publication.

2-42 EDCS-202049
Common Configuration Mistakes

The following sections outline some common mistakes and problems encountered when configuring
IPSec:
• ACL Mirroring Error
• Peer Address Mismatch
• Transform Set Mismatch
• IKE Policy Mismatch
ACL Mirroring Error

The access lists that define the traffic to be encrypted must be mirror images of each other. The source
port and source address in the access list on one peer must match the destination port and destination
address on the other peer. The elimination of the source and destination ports is permissible, however
the use of the keyword any for the addresses is strongly discouraged. This will ensure proper processing
of encrypted traffic on the remote peer.
Peer Address Mismatch

The IP address used as the IPSec source address must match the address configured as the destination
address on the IPSec peer and vice-versa. Unless the address is configured specifically, the address of
the outgoing interface will be used as the IPSec peer’s address.
Transform Set Mismatch

At least one matching transform set must be configured between two IPSec peers. When specifying a
particular strength of encryption algorithm, a similar strength IKE algorithm should also be configured.
Failure to do so could weaken the encryption strength of the entire solution.
IKE Policy Mismatch

There is a default IKE policy present in all Cisco IOS devices. This policy uses lower security hash
methods and encryption transform sets. If a stronger IKE policy is desired, at least one matching IKE
policy must be configured between each IPSec peer.
Note It is recommended to use the same transform set and hash methods in IKE and IPSec policies.

EDCS-202049 2-43

2-44 EDCS-202049
A P P E N D I X A
Enterprise Site-to-Site VPN Scalability Test
Configuration
Scalability Testbed Network Diagram

Figure A-1 illustrates the test network used for the enterprise site-to-site VPN scalability tests presented
in this publication.

EDCS-202049 A-1
Appendix A Enterprise Site-to-Site VPN Scalability Test Configuration
Figure A-1 Scalability Testbed Network Diagram
Chariot "Core / Campus endpoints"

endpoints Sun Netras: vpn4-n1 through vpn4-n30
Chariot vpn4-2948GL2
console
vpn2-6500-1
Si
vpn3-7xx0-1 vpn3-7xx0-3
vpn3-7xx0-2
Si vpn1-6500-1
vpn2-7505-1 vpn2-7500-2
FEC FEC
(HDLC)
vpn6-2948G-1 vpn6-2600-1 vpn10-2600-1 vpn10-2948G-1

through through
vpn6-2600-30 vpn10-2600-30
vpn7-2948G-1 vpn7-2600-1 vpn11-2600-1 vpn11-2948G-1

through through
vpn7-2600-30 vpn11-2600-30
vpn8-2948G-1 vpn8-2600-1 vpn12-2600-1 vpn12-2948G-1

through through
vpn8-2600-30 vpn12-2600-30
vpn9-2948G-1 vpn9-2600-1 vpn14-3620-1-5 vpn13-800 - 1-5 ci13-2948G-1

through vpn14-3660-1-5 vpn13-1700-1-5
vpn9-2600-30 vpn14-2948G-1 vpn13-2600-1-5
vpn13-3640-1-5
"Branch endpoints" vpn2-6500-2

Si
Sun Netras: vpn5-n1 VPN Solution Testbed
through vpn5-n30
vpn5-2948GL2-1
74182
Chariot
endpoints

A-2 EDCS-202049
Scalability Testbed Configuration Files

The configuration for the central and branch sites are listed below in the sections which follow.
Note These configurations have been extracted from real configurations used in ESE scalability testing. They
are provided as a reference only.
The use of GRE as a tunneling method requires static tunnel endpoint configuration. Configuring IPSec
peers was also done statically.
Head-end Configuration
The head-end is setup with two GRE tunnels (one primary and one secondary) for each branch site that
it terminates. The following configuration is an excerpt and does not contain configuration commands
for all branches.
!
ip cef
!
!
ip ssh time-out 120
ip ssh authentication-retries 3
!
xsm
xsm privilege configuration level 15
xsm privilege monitor level 1
xsm vdm
xsm edm
no xsm history vdm
no xsm history edm
!
!
encr 3des
!
!
crypto mib ipsec flowmib history tunnel size 200
crypto mib ipsec flowmib history failure size 200
!
crypto map static-map local-address FastEthernet1/0
set peer 192.168.1.2
set peer 192.168.2.2
!
!
controller ISA 2/1
!
!
!
buffers small permanent 2048

EDCS-202049 A-3
buffers small max-free 10240

buffers small min-free 512
buffers middle permanent 2048
buffers middle max-free 10240
buffers middle min-free 512
buffers big permanent 2048
buffers big max-free 10240
buffers big min-free 512
buffers verybig permanent 2048
buffers verybig max-free 10240
buffers verybig min-free 512
buffers large permanent 2048
buffers large max-free 10240
buffers large min-free 512
buffers huge permanent 128
buffers huge max-free 512
buffers huge min-free 32
!
!
interface Loopback0
ip address 10.57.1.255 255.255.255.255
no ip route-cache
no ip mroute-cache
!
interface Tunnel1
description vpn6-2600-1
ip address 10.62.1.193 255.255.255.252
load-interval 30
!
interface Tunnel2
description vpn6-2600-2
ip address 10.62.2.193 255.255.255.252
load-interval 30
!
!
ip address 172.26.156.17 255.255.254.0
no ip mroute-cache
load-interval 30
duplex full
!
ip address 192.168.251.1 255.255.255.0
load-interval 30
duplex full
speed 100
!
ip address 10.57.1.1 255.255.255.252
no ip proxy-arp
load-interval 30
duplex full

A-4 EDCS-202049
speed 100
!
router eigrp 1
redistribute static
passive-interface FastEthernet0/0
network 10.0.0.0
no auto-summary
!
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.251.2
!
!
ip access-list extended vpn-static1
permit gre host 192.168.251.1 host 192.168.1.2
Branch Site Configuration

For resiliency, two tunnels are configured (primary and secondary) to the central site.
!
ip cef
!
!
encr 3des
!
!
crypto mib ipsec flowmib history tunnel size 200
crypto mib ipsec flowmib history failure size 200
!
crypto map static-map local-address Serial0/0
set peer 192.168.253.1
set peer 192.168.251.1
!
!
interface Loopback0
ip address 10.63.25.254 255.255.255.255
!
interface Tunnel0
description Tunnel0
ip address 10.63.25.194 255.255.255.252
load-interval 30
!
interface Tunnel1
description Tunnel1

EDCS-202049 A-5
delay 1526
ip address 10.63.25.198 255.255.255.252
load-interval 30
!
ip address 172.26.157.185 255.255.254.0
no ip proxy-arp
no ip mroute-cache
load-interval 30
speed auto
half-duplex
!
interface Serial0/0
description Serial0/0
bandwidth 1536
ip address 192.168.185.2 255.255.255.0
no ip mroute-cache
load-interval 30
no fair-queue
!
ip address 10.63.25.1 255.255.255.128
no ip mroute-cache
load-interval 30
speed 10
full-duplex
!
router eigrp 1
passive-interface Serial0/0
network 10.0.0.0
no auto-summary
!
ip classless
ip route 192.168.251.1 255.255.255.255 192.168.185.1
ip route 192.168.253.1 255.255.255.255 192.168.185.1
no ip http server
ip pim bidir-enable
!
!
!

A-6 EDCS-202049
A P P E N D I X B
High-Level IPSec Overview
The purpose of this section is to provide a brief introduction to IPSec and its application in VPNs.
General descriptions of the following IPsec topics are presented:
• Tunneling Protocols
• Introduction to IPSec
• IPSec Protocols
• IPSec Modes
• Internet Key Exchange (IKE)
For a more in-depth understanding of IPSec, the reader should consult the Cisco SAFE VPN White Paper.
Cisco SAFE documentation can be found at the following URL:
Tunneling Protocols
There are a variety of tunneling protocols from which to choose. They vary in terms of the features they
support, the problems they are designed to solve, and the amount of security they provide to the data
being transported.
The design presented in this paper focuses on IPSec used in conjunction with GRE tunnels. When
implemented individually, these tunneling protocols do not provide the necessary features to
simultaneously ensure privacy and support multi-protocols. The combination of IPSec and GRE
concurrently achieves both functions.
Other tunneling protocols include Point-to-Point Tunneling Protocol (PPTP) and Layer 2 Tunneling
Protocol (L2TP). PPTP and L2TP are intended for user or client to concentrator networks, commonly
called remote access solutions and are not used in the site-to-site VPN solution.
Introduction to IPSec
The IPSec standard provides a method to manage authentication and data protection between multiple
peers engaging in secure data transfer. IPSec includes Internet Security Association & Key Management
Protocol (ISAKMP) and the Oakley Key Determination Protocol and two IPSec IP
protocols—Encapsulating Security Protocol (ESP) and Authentication Header (AH).

EDCS-202049 B-1
Appendix B High-Level IPSec Overview
IPSec Protocols
IPSec uses symmetrical encryption algorithms for data protection. Symmetrical encryption transforms
are more efficient and are easier to implement in hardware. These algorithms need a secure method of
key exchange in order to ensure the data protection. Internet Key Exchange’s (IKE) ISAKMP/Oakley
protocols provide that capability.
This solution requires a standards based way to secure data from eavesdropping and modification. IPSec
provides such a method. IPSec permits the network designer to choose the strength of data protection by
allowing the choice of transform set. IPSec also has several hash methods to choose from, each giving
different levels of protection.
IPSec Protocols
There are two IP protocols used in the IPSec standard: Encapsulating Security Protocol (ESP) and
Authentication Header (AH). These protocols are summarized briefly in the next two sections:
• Encapsulating Security Protocol (ESP)
• Authentication Header (AH)
Encapsulating Security Protocol (ESP)

The ESP header (IP protocol 50) forms the core of the IPSec protocol. This protocol in conjunction with
an agreed upon encryption method or transform set, protects data by rendering it un-decipherable. This
protocol protects the data portion of the packet only. It can also optionally provide for authentication of
the protected data. Figure B-1 shows how ESP encapsulates an IP packet:

B-2 EDCS-202049
IPSec Protocols
Figure B-1 Encapsulating Security Protocol (ESP)
Original IP Packet IP HDR Data
Transport Mode ESP ESP

IP HDR ESP HDR Data
trailer Auth
Encrypted
Authenticated
Tunnel Mode
ESP ESP
New IP HDR ESP HDR IP HDR Data
trailer Auth
Encrypted
74169
Authenticated

EDCS-202049 B-3
IPSec Protocols
Authentication Header (AH)

The AH protocol (IP protocol 51) forms the other part of IPSec. The AH does not protect data in the
usual sense by hiding the data. Instead, it adds a tamper-evident seal to the data. It also protects the
non-mutable fields in the IP header carrying the data. This includes the address fields of the IP header.
The AH protocol should not be used alone when there is a requirement for data confidentiality.
Figure B-2 illustrates how AH encapsulates an IP packet:
Figure B-2 Authentication Header (AH)
Original IP Packet IP HDR Data
Transport Mode IP HDR AH Data
Authenticated except for mutable fields
Tunnel mode
New IP HDR AH IP HDR Data
74170
Authenticated except for mutable fields in New IP header

B-4 EDCS-202049
IPSec Modes
IPSec Modes
IPSec has two methods of forwarding data across a network: transport mode and tunnel mode. Each
differs in their application as well as in the amount of overhead added to the passenger packet. These
protocols are summarized briefly in the next two sections:
• Tunnel Mode
• Transport Mode
Tunnel Mode
Tunnel mode works by encapsulating and protecting an entire IP packet. Because tunnel mode
encapsulates or hides the IP header of the packet, a new IP header must be added in order for the packet
to be successfully forwarded. The encrypting devices themselves own the IP addresses used in these new
headers. These addresses can be specified within the configuration of Cisco IOS routers. Tunnel mode
may be employed with either or both ESP and AH. Using tunnel mode results in additional packet
expansion of approximately 20 bytes associated with the new IP header. Tunnel mode expansion of the
IP packet is depicted in Figure B-3.
Figure B-3 IPSec Tunnel Mode
IP HDR Data
New IP HDR IPsec HDR IP HDR Data
74171
To be protected

EDCS-202049 B-5
Internet Key Exchange (IKE)
Transport Mode
Because packet expansion can be a concern during the forwarding of small packets, a second forwarding
method was also specified. IPSec transport mode inserts the ESP header between the IP header and the
next protocol or the transport layer of the packet.
Both IP addresses of the two network nodes whose traffic is being protected by IPSec are visible. This
mode of IPSec can be sometimes susceptible to traffic analysis. However, since there is no additional IP
header added, it results in less packet expansion. Transport mode can be deployed with either or both
ESP and AH. This mode works well with GRE because GRE hides the addresses of the end stations by
adding its own IP header. Transport mode expansion of the IP packet is depicted Figure B-4.
Figure B-4 IPSec Transport Mode
IP HDR Data
IP HDR IPsec HDR Data
74172
To be protected

In order to implement a VPN solution with encryption, periodic changing of encryption keys is
necessary. Failure to change these keys would make the network susceptible to brute force attacks.
IPSec solves the problem of key generation with the Internet Key Exchange (IKE) protocol. This
protocol uses a mathematical routine called a Diffie-Hellman exchange to generate symmetrical keys to
be used by two IPSec peers. IKE also manages the negotiation of other security parameters such as the
data to be protected, the strength of the keys, the hash methods used and whether or not the packets are
protected from replay. IKE utilizes UDP port 500.
Two elements of IKE are discussed briefly in the following sections:
• Security Association (SA)
• IKE Authentication

B-6 EDCS-202049
Security Association (SA)

A Security Association (SA) is an agreement between two peers engaging in an IPSec exchange. This
agreement includes things like the type and strength of the encryption used to protect the data. It includes
the method and strength of the data authentication (if any) and also the method of creating new keys for
that data protection. SAs are performed in two phases as described in the following two sections:
• IKE Phase 1
• IKE Phase 2
IKE Phase 1
Phase 1 is the initial negotiation of SAs between two IPSec peers. Phase 1 can optionally also include
an authentication in which each peer is able to verify the identity of the other. This interaction between
two IPSec peers can be subject to eavesdropping with no significant vulnerability of the keys being
recovered. Phase 1 SAs are bi-directional—data may be sent and received using the same key material
generated.
Phase 1 has three possible authentication methods: pre-shared keys (PSK), Digital Certificates, or RSA
Encryption (encrypted nonces). This publication focuses on pre-shared keys implementations.
IKE Phase 2
Phase 2 SAs are negotiated by the IKE process (ISAKMP) on behalf of other services such as IPSec, that
need key material for operation. Since the SAs used by IPSec are unidirectional, a separate key exchange
is needed for data flowing in the forward direction from the reverse direction. This doubles the amount
of eavesdropping effort that would be required to successfully recover both sides of an interaction.
IKE Authentication
The two primary methods of configuring VPN devices to authenticate with their respective peers are:
• Pre-shared Keys
• Digital Certificates
These are discussed briefly in the sections that follow.
Pre-shared Keys
Implementing pre-shared keys involves configuration using a set of keys known in advance to both peer
VPN devices.
As the number of IPSec devices in the VPN grows, scalability becomes an issue because a separate key
must be maintained for each IPsec peer. Replacement of a device in the network could also lead to
compromise of the keys in use at the time.
The scalability testing performed for this publication utilized the pre-shared keys method of
authentication.

EDCS-202049 B-7
Digital Certificates
An alternative to the pre-shared keys method is to implement the use of digital signatures contained in
digital certificates. Digital signatures use a trusted third party, known as a certificate authority, to
digitally sign the public key portion of the encrypted nonce.
Included with the signature is a name, serial number, validity period and other information that an IPSec
device can use to determine the validity of the certificate. Certificates can also be revoked, denying the
IPSec device the ability to successfully authenticate.
The discussion and setup of a certificate authority is beyond the scope of this paper.

B-8 EDCS-202049
I N D EX
access list for encryption 2-40

A
applying crypto maps 2-41
aggregation (figure) 2-12 common mistakes 2-43
AH crypto map 2-41
packet (figure) B-4 convergence
Authentication Header. See AH. scenario summary 2-29
crypto map
dynamic 2-42
B
best practices summarized 2-8

D
branch site
sizing 2-27 data encryption
VPN router 2-28 IPSec 2-9
Data Encryption Standard. See DES.
Dead Peer Detection. See DPD.
C
deployment considerations (table) 2-7
case study DES
branch site sizing 2-37 compared to Triple DES 2-9
design considerations 2-35 design
enterprise site-to-site VPN 2-33 assumptions 2-3
head end sizing 2-36 components summary 2-3
network layout 2-38 enterprise site-to-site VPN topology (figure) 2-4
Cisco IOS resiliency 2-10
pre-classification 2-31 DHCP 2-20
releases evaluated 2-30 digital certificates B-8
configuration dynamic crypto map
summary 2-39 IPSec 2-42
configuration discussion Dynamic Host Configuration Protocol. See DHCP.
access list configuration 2-40
applying crypto maps 2-41
E
common configuration mistakes 2-43
crypto map configuration 2-41 EIGRP
configuration example as part of VPN design 2-10

EDCS-202049 IN-1
Index
configuration fragment 2-14 placement of firewall 2-18

head-end aggregation effects 2-24 sizing 2-23
recommended for VPN 2-13 VPN router 2-26
use with GRE (table) 2-8
Encapsulating Security Protocol. See ESP.
I
encryption
Cisco recommendation 2-22 IKE
hardware accelerated 2-22 authentication B-7
hardware versus software 2-32 Diffe-Hellman exchange B-6
software-based 2-21, 2-32 digital certificates B-8
encryption algorithms keepalives 2-16
DES 2-9 pre-shared keys B-7
Triple DES 2-9 security association (SA) B-7
Enhanced Interior Gateway Routing Protocol. See EIGRP. Internet Key Exchange. See IKE.
ESP IP addressing
packet (figure) B-3 IPSec 2-19
summarized B-2 IP multicast
EIGRP 2-4
IPSec 2-20
F
AH packet (figure) B-4
firewalls compressed RTP not supported 2-32
multicast (note) 2-19 data encryption 2-9
DHCP 2-20
dynamic crypto map 2-42
G
ESP packet (figure) B-3
Generic Route Encapsulation. See GRE. IP addressing 2-19
GRE multicast 2-19
multicast 2-19 NAT 2-20
packet expansion 2-17 packet expansion 2-17
protocol overview 2-9 protocols B-2
routing protocols 2-19
technology overview B-1
H transport mode B-6
hash method tunnel mode B-5
MD5 2-9 IP Security. See IPSec.

SHA-1 2-9 IP Telephony
head-end latency considerations 2-30
load distribution 2-11

IN-2 EDCS-202049
Index
PAT
K
issues with IPSec VPN 2-20
keys performance
pre-shared 2-42 scenario summary 2-29
Port Address Translation. See PAT.
pre-classification 2-31
L
pre-shared keys 2-42, B-7
load distribution products
head-end 2-11 VPN components summary (table) 2-5
low-speed lines
QoS and VPN 2-32
Q
QoS
M
IP Telephony support mechanisms 2-31
Maximum Transmission Unit. See MTU. Quality of Service. See QoS.
MTU
discovery 2-18
R
multicast
firewalls 2-19 reverse route injection 2-17
GRE 2-19 route propagation
IPSec 2-19 recommended strategy 2-13
support over VPN 2-19 routing protocols
alternatives to using 2-16
EIGRP 2-4, 2-10, 2-13, 2-21
N
IPSec 2-19
NAT OSPF 2-13
IPSec 2-20 using across VPN 2-13
Network Address Translation. See NAT.
S
O
scalability testing
OSPF branch site configuration A-5
use in VPN 2-13 configuration example A-3
head-end configuration A-3
methodology 2-21
P
network diagram A-2
packet expansion service-level agreement. See SLA.
IPSec/GRE (figure) 2-17 service provider. See SP.

EDCS-202049 IN-3
Index
SLA
key elements 2-20
SP
dependencies 2-20
VPN considerations 2-32
split tunneling 2-19
starting assumptions 2-3
topology
alternatives 2-13
hub-and-spoke 2-2
Triple DES
compared to DES 2-8
troubleshooting
common configuration mistakes 2-43
tunnel
aggregation (figure) 2-12
primary and secondary 2-10
protocols B-1
split 2-19
VPN configuration (figure) 2-11
virtual primate network. See VPN.

VPN
Cisco product summary (table) 2-5
design resiliency 2-10
encryption algorithms 2-9
hub-and-spoke topology (figure) 2-2
routing protocols 2-13
site-to-site best practice summary (table) 2-8
site-to-site deployment considerations (table) 2-7
site-to-site topology (figure) 2-4
tunneling protocols B-1

IN-4 EDCS-202049

Cisco AAVID Enterprise VPN Design

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Cisco AAVID Enterprise VPN Design

Загружено:

Авторское право:

Доступные форматы

Cisco AVVID Network Infrastructure

Enterprise Site-to-Site VPN Design

Customer Order Number: 956377

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

CHAPTER 1 Cisco AVVID Network Infrastructure VPN Solution Overview 1-1

CHAPTER 2 Enterprise Site-to-Site IPSec VPNs 2-1

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

Alternatives to Using a Routing Protocol 2-16

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

Preliminary Design Considerations 2-35

APPENDIX A Enterprise Site-to-Site VPN Scalability Test Configuration A-1

APPENDIX B High-Level IPSec Overview B-1

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

Digital Certificates B-8

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

This preface summarizes the following general topics:

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

World Wide Web

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

Obtaining Technical Assistance

Technical Assistance Center

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

Cisco TAC Web Site

Cisco TAC Escalation Center

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

Site-to-Site VPN Benefits

Table 1-1 VPN Solution Benefits Summary

Solution Design Criteria VPN Benefits

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

References and Reading

Table 1-2 Request For Comment (RFC) Papers

Table 1-3 Related Enterprise VPN Websites

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

Figure 2-1 Hub-and-Spoke VPN

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

Figure 2-2 VPN Solution Network Topology

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

Cisco VPN Product Overview

Table 2-1 Cisco VPN Product Applications Summary

VPN Router Maximum Scalability Traffic Mix

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

Solution Design Recommendations

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

General Design Considerations

Table 2-2 General Site-to-site VPN Deployment Considerations

Solution Design Criteria Solution Question VPN Design Relevance

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

Table 2-3 Enterprise Site-to-site IPsec-based VPN Best Practice Summary

Deployment Objective Best Practice Summary

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

IPSec for Data Encryption

With hardware-accelerated encryption implemented, performance is not significantly affected by choice

Implementing Generic Route Encapsulation (GRE)

Figure 2-3 GRE as a Carrier Protocol of IP

IP GRE Network packet

Transport Carrier Passenger

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design

Ensuring High Availability and Resiliency

Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design