Table Of Contents
Point-to-Point GRE over IPsec Design Overview
Quality of Service per p2p GRE Tunnel Interface
Single Tier Headend Architecture
Dual Tier Headend Architecture
Single Tier Headend Architecture versus Dual Tier Headend Architecture
Static p2p GRE over IPsec with a Branch Static Public IP Address
Static p2p GRE over IPsec with a Branch Dynamic Public IP Address
Best Practices and Known Limitations
Point-to-Point GRE over IPsec Design Overview
This chapter provides an overview of the VPN site-to-site design topology and characteristics. Chapter 2, "Point-to-Point GRE over IPsec Design and Implementation," provides more detail on the design considerations. Chapter 3, "Scalability Considerations," presents Cisco product options for deploying the design.
Starting Assumptions
The design approach presented in this design guide makes the following starting assumptions:
•
The design supports a typical converged traffic profile for customers (see Chapter 4, "Scalability Test Results (Unicast Only)."
•
•
•
•
•
Quality of Service per p2p GRE Tunnel Interface
All headend scalability results were performed on various Cisco platforms. Results were obtained without a hierarchical class-based weighted fair queueing service policy applied per p2p GRE tunnel interface. This QoS configuration is a parent service policy that shapes packets in the logical tunnel interface and then queues packets within the shaped rate in a child service policy.
Applying a hierarchical class-based weighted fair queueing service policy to the p2p GRE tunnel interface may require packets to be process-switched while the shaper is active; thus, it is CPU intensive.
Note
Design Components
VPNs have many applications, including extending reachability of an enterprise WAN, or replacing classic WAN technologies such as leased lines, Frame Relay, and 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 multiprotocol 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 VPN routers are a good choice for site-to-site VPN deployments because they can accommodate any network requirement inherited from a Frame Relay or private line network, such as support for IP multicast and latency-sensitive traffic, routing for resiliency, and support for non-IP protocols such as IPX or SNA. See Chapter 3, "Scalability Considerations," for a discussion on selection of headend and branch products.
Topology
In a p2p GRE over IPsec design, the following three topologies can be implemented:
•
•
•
The hub-and-spoke topology is discussed in this design guide because it is the most widely deployed.
Headend System Architectures
This section describes the two headend system architectures that can be implemented, depending on the scalability requirements.
Single Tier Headend Architecture
In a Single Tier Headend Architecture, both the p2p GRE and crypto functionally co-exist on the same router CPU. Figure 1-1 shows this hub-and-spoke topology.
Figure 1-1 Single Tier Headend Architecture
Figure 1-1 shows a hub-and-spoke network with multiple headend devices for redundancy. Headends are p2p GRE and crypto tunnel aggregation routers servicing multiple p2p GRE over IPsec tunnels for a prescribed number of branch office locations. In addition to terminating the VPN tunnels at the central site, headends can advertise branch routes using IP routing protocols such as EIGRP or OSPF.
Dual Tier Headend Architecture
In a Dual Tier Headend Architecture, the p2p GRE and crypto do not functionally co-exist on the same router CPU. Figure 1-2 shows this hub-and-spoke topology.
Figure 1-2 Dual Tier Headend Architecture
Figure 1-2 shows a hub-and-spoke network with multiple headend devices for redundancy. p2p GRE headends as well as crypto headends together service multiple p2p GRE over IPsec tunnels for a prescribed number of branch office locations. In addition to terminating the VPN tunnels at the central site, the p2p GRE headends can advertise branch routes using IP routing protocols such as EIGRP or OSPF.
Single Tier Headend Architecture versus Dual Tier Headend Architecture
The choice between the Single Tier Headend Architecture and the Dual Tier Headend Architecture depends on the following criteria:
•
•
•
In either architecture, the topology being designed is the first consideration. For this comparison, a hub-and-spoke topology is the only topology detailed because this discussion is focused on the headend router. Table 1-1 lists the technical limitations of the two architectures.
Tunnel protection requires the same source and destination IP address for both the GRE tunnel and the crypto tunnel; therefore, it is not a valid option in a Dual Tier Headend Architecture. Both architectures support all of the options above as a hub-and-spoke topology.
When considering performance and value, the two should be considered together. Performance is based on the number of packets a router can forward in a given timeframe, or packets per second (pps). Value is the price for a specific router based on the pps rate. Given these two considerations, Table 1-2 shows both price and performance for the primary headend router choices currently available.
For the purpose of this design guide, these prices are not the actual price of the specific platforms because prices change on a periodic basis. The prices are provided as a reference to show the value of one architecture over the other. The reader should obtain specific pricing per platform when comparing the platforms. However, the pps values have been verified in Cisco testing.
With this is mind, now consider the value for each of the architectures, given the performance numbers stated for a p2p GRE over IPsec design. The Single Tier Headend Architecture is the easiest to demonstrate because both the p2p GRE and encryption processes are housed on a single routing processor. Table 1-3 shows these results.
Note from this comparison that the break-even point regarding value per performance is approximately 120 Kpps at $100,000. Below this price point, the clear choice is to deploy multiple Cisco 7200VXRs with NPE-G1 and Dual SA-VAM2+; however, above this point, the decision is much different. To obtain the same 520 Kpps with the Cisco 7200VXR with NPE-G1 and Dual SA-VAM2+ solution, it requires thirteen chasses at a cost of $390,000, versus a single Cisco 7606 with Sup720, SSC400, and VPN SPA at $100,000. The difference represents a substantial capital savings over the long term. Also, support contracts are increased from one to thirteen as well.
The Dual Tier Headend Architecture is slightly harder to demonstrate because the p2p GRE and encryption processes are housed on separate routing processors. Table 1-4 shows these results.
Note from this comparison that the break-even point regarding value per performance is approximately 200 Kpps at $150,000. Below this price point, the clear choice is to deploy multiple Cisco 7200VXRs with NPE-G1 and Dual SA-VAM2+; however, above this point, the decision is much different. To obtain the same 600 Kpps with the Cisco 7200VXR with NPE-G1 and Dual SA-VAM2+ solution, it requires fifteen chasses at a cost of $450,000, versus a single Cisco 7606 with Sup720, SSC400, and VPN SPA with three Cisco 7200VXRs with NPE-G1 at $160,000. The difference represents a substantial capital savings over the long term. Also, support contracts are increased from 4 to 15 as well.
Branch Router Considerations
Branches are typically access routers that provide p2p GRE over IPsec tunnel(s) from the branch office locations to the central site. In addition to terminating the VPN tunnels, the branch router often provides WAN access, and in some implementations may serve as a firewall.
Static p2p GRE over IPsec with a Branch Static Public IP Address
In this scenario, the public IP address of the branch router is a statically defined IP address. Both the p2p GRE and crypto tunnels are sourced from this statically defined public IP address.
Static p2p GRE over IPsec with a Branch Dynamic Public IP Address
In this scenario, the public IP address of the branch router is a dynamically assigned IP address. The p2p GRE tunnel is sourced from a loopback interface with an administratively assigned private IP address. The crypto tunnel is sourced from the dynamically assigned public IP address. A static host route is required in the headend router to ensure p2p GRE packets destined to the branch router loopback interface are encrypted.
High Availability
Network resiliency is provided differently depending on the initial network requirements. This design guide uses a dynamic IGP routing protocol across the VPN. Because IPsec does not provide the ability to run protocols requiring IP multicast (such as EIGRP), it is necessary to use p2p GRE in conjunction with IPsec. p2p GRE supports more diverse traffic across the VPN, including IP multicast and non-IP protocols.
For high availability in the case of a failure, each branch access router should have two p2p GRE over IPsec tunnels, a primary and secondary, provisioned to different headend tunnel aggregation routers. This is discussed further in High Availability, page 2-17.
Best Practices and Known Limitations
The following sections contain a summary of the best practices and limitations for the design. More detailed information is provided in Chapter 2, "Point-to-Point GRE over IPsec Design and Implementation."
Best Practices Summary
The following list summarizes the best practices for a p2p GRE over IPsec design, supporting multiprotocol and/or IP multicast traffic including routing protocols:
•
–
–
–
–
–
–
–
–
•
–
–
–
–
•
•
•
•
–
•
–
–
•
•
•
–
–
Known Limitations Summary
The following lists at a high level the known limitations for a p2p GRE over IPsec VPN design:
•
–
–
•
•
•
–
–
–
–
•
–
•
–
•
–
–
Additional detailed information on these recommendations is discussed in the chapters that follow.
