V3PN: Redundancy and Load Sharing Design Guide
V3PN: Redundancy and Load-Sharing Introduction
Downloads: This chapterpdf (PDF - 373.0KB) The complete bookPDF (PDF - 5.2MB) | Feedback

V3PN: Redundancy and Load-Sharing Introduction

Table Of Contents

V3PN: Redundancy and Load-Sharing Introduction

Introduction

Solution Overview

Small Branch Deployments

Large Branch Deployments

General Deployment and V3PN Redundancy Issues


V3PN: Redundancy and Load-Sharing Introduction


This design guide defines the comprehensive functional components required to build an enterprise virtual private network (VPN) solution that can transport IP telephony and video. This design guide identifies the individual hardware requirements and their interconnections, software features, management needs, and partner dependencies, to enable customers to deploy, manage, and maintain an enterprise VPN solution.

This design overview is part of a series of design guides, each based on different technologies for the IPsec VPN WAN architecture. (See Figure 1.) Each technology uses IPsec as the underlying transport mechanism for each VPN.

Figure 1 IPsec VPN WAN Design Guides

This chapter includes the following sections:

Introduction

Solution Overview

General Deployment and V3PN Redundancy Issues

Introduction

This design and implementation guide extends the Cisco Architecture for Voice, Video, and Integrated Data (AVVID) by enabling applications such as voice and video to be extended to emerging WAN media. Previous VPN design guides have focused on Internet T1, Frame Relay, and the broadband offerings of DSL and cable.

This design guide builds on the Voice and Video Enabled IPSec VPN (V3PN) SRND at the following Urlhttp://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/V3PN_SRND/V3PN_SRND.html.

The pressure to reduce recurring WAN expenses has led to increasing customer acceptance of emerging WAN media, along with the need to provide design guidance for implementation of broadband as a backup technology to traditional WAN media. Additionally, customers are implementing broadband circuits as the primary WAN media and look to traditional dial solutions to provide backup to the broadband circuit.

Situations in which a single T1 bandwidth is not sufficient but a T3 is more bandwidth and more costly than required encourage the implementation of multiple T1 circuits. In these instances, customers often struggle with the best means of providing load sharing when the visibility to individual data flows are hidden within an IPSec tunnel.

This guide provides guidance for designs in which new broadband offerings are used in conjunction with traditional WAN media. The focus remains enabling quality of service (QoS) to support voice; however, some deployments may not offer sufficient bandwidth to provide voice support on all interfaces. These issues are articulated in this guide.

Many of these designs apply in environments where QoS is enabled to support point-of-sale or financial transactions in place of voice.

Solution Overview

This solution is delineated in two main components:

Small Branch Deployments

Large Branch Deployments

Small Branch Deployments

This design guide describes seven models within the small branch deployment category. The first example shows a customer implementation of triggering dial backup by using a generic routing encapsulation (GRE) tunnel and enabling keepalives within the tunnel to verify connectivity and to trigger dial backup upon loss of connectivity. The GRE tunnel in this example does not encapsulate end-user data traffic; the tunnels only purpose is to verify connectivity. This implementation does not require any new features because the GRE Tunnel Keepalive feature was released in Cisco IOS Release 12.2(8)T. There is no requirement to run a routing protocol or to configure IP addressing for the GRE tunnel.

Several of the small branch deployment models make use of the Reliable Static Routing Backup Using Object Tracking feature introduced in Cisco IOS Release 12.3(2)XE for implementing dial backup on the Cisco 1700 Series routers.

Use of the ip dhcp-client default-router distance command is the key to using a primary interface that obtains its IP address via DHCP. An example is shown using cable as the primary interface with DSL as the backup interface, but could also be used as a configuration guide if Async or Basic Rate Interface (BRI) is used in place of the backup DSL interface. Both Async and BRI configurations are shown in the sample deployments.

The wireless broadband deployment model shows a Cisco 1711 configured with three WAN interfaces: the wireless broadband interface, an interface to a DSL router, and an Async dial-up interface. You can connect any of the three interfaces to the router to establish connectivity, or you can connect them all for high availability.

From an IPSec authentication standpoint, use of digital certificates, EZVPN, and initiating and responding to Internet Key Exchange (IKE) aggressive mode with pre-shared keys are illustrated. Some of these features were incorporated in Cisco IOS 12.2(15)T (crypto isakmp profile and crypto keyring), and responding to IKE aggressive mode is a Cisco IOS 12.3 feature.

One small branch deployment model uses a Cisco IOS IPSec head end for the primary connectivity and a Cisco VPN 3080 Concentrator for the dial backup connectivity.

Large Branch Deployments

The following three large branch deployments are described:

Frame Relay with broadband load sharing and backup

Multilink point-to-point protocol (MLPPP)

Inverse multiplexing over ATM (IMA)

There were no surprises with Multilink PPP or IMA: these chapters and the test results are included and tested as a verification of capability. However, a video conference traffic stream was added in one of the tests because one rationale for bandwidth greater than a single T1/E1 is to include video conferencing to a remote location.

The chapter on Frame Relay with broadband load sharing and backup is most applicable for retail store locations that are currently using a traditional Frame Relay network, but want to take advantage of low cost broadband connections to supplement the existing bandwidth and provide an always available backup path. There will be an increasing migration from Frame Relay to broadband, and this method can also be used as a transition phase that minimizes the risk of a wholesale cutover from one technology to another.

General Deployment and V3PN Redundancy Issues

Each chapter in this guide depicts a specific deployment model, and can be used as a self-contained entity, in that the relevant configuration examples for both the remote and head-end routers are illustrated where practical.

However, these deployment models can also be mixed and matched. For example, the chapter showing the use of GRE tunnels to verify connectivity uses DSL as the primary path with Basic Rate ISDN as the back-up connection could draw configuration examples for Async as backup and be a perfectly acceptable design.

The following general assumptions are made:

DSL examples show the use of PPP over Ethernet (PPPoE) with the PPPoE session terminating on the IPSec router. If in customer deployments of DSL, PPPoE is not used or is terminated on a service provider or separate router, the IPSec router obtains its outside IP address via DHCP from the upstream router. In this case, the DSL connection is similar to the outside interface configuration used for cable.

For broadband examples, the IP address of the remote router is dynamically assigned. As such, the head-end IPSec routers implement dynamic crypto maps.

Some form of QoS is applied to support voice or mission-critical applications. Although voice is not always a requirement for small branch deployments, mission-critical applications such as credit card authorizations or other point-of-sale applications benefit from QoS where practical.

If voice cannot be provisioned because of lack of bandwidth, for example with Async backup, some means of blocking voice is implemented on the router. The goal is to allow voice calls where possible but never to provide a call appearance but not a reasonable expectation of acceptable voice quality.

IPSec encryption is implemented not only for user data traffic but also for control plane traffic such as GRE keepalives or Service Assurance Agent (SAA) probes. Digital certificate and RADIUS servers are also accessed through an IPSec tunnel from the remote routers to the head end; there should be no need to expose these servers to the Internet without protection from some firewall and intrusion detection system (IDS) scheme.

It should be expected and practical to implement multiple head-end devices, WAN and IPSec routers or concentrators to provide redundancy at the central site. A single link or device failure should not cause an unrecoverable outage.

This guide provides reasonably complete configuration examples, but assumes the reader is familiar with other V3PN design guides and best practices of network security.

Each chapter describes a particular deployment model and is intended to be a complete review of the concepts and configurations required to implement the design.