Designing Virtual Private Networks © 2004 Cisco Systems, Inc. All rights reserved. Designing Site-to-Site VPNs ARCH v1.29-1. - презентация

1 Designing Virtual Private Networks © 2004 Cisco Systems, Inc. All rights reserved. Designing Site-to-Site VPNs ARCH v1.29-1

2 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Site-to-Site VPN Solution Connects branch offices to central site Key characteristics –Full mesh or hub-and-spoke –Tunneling –Routing protocol –Data plus voice and video Devices –Head-end: VPN-enabled routers –Remote: VPN-enabled routers –Hardware encryption Key Objectives VPN product performance, aggregation per head-end, resiliency, and scalability Hardware encryption at remote sites

3 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Comparing Private WANs and VPNs Private WANSite-to-Site VPN Advantages Reliability Secure Controlled Self-managed Globally available Redundant Less expensive Greater connectivity Simplified WAN Alternative to dial-on-demand for backup Performance Scaling challenge Local skill required Investment in technology Reliance on third parties Requires encryption and client management Lack of control

4 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Designing Site-to-Site VPN Solutions 1. Determine application and data needs. 2. Design the VPN topology between sites. 3. Incorporate design resiliency and failover mechanisms. 4. Choose head-end products based on predicted VPN capacity requirements.

5 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Hub-and-Spoke VPN Topologies One-to-ManyMany-to-Many

6 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Simple Full-Mesh VPN Topology

7 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Hierarchical VPN Topology

8 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v High-Availability and Resiliency Considerations Implement primary and secondary tunnels between each branch device and the central site for resiliency. Allocate primary tunnels to balance load on head-ends. Allocate secondary tunnels to balance load after failover to surviving head-ends.

9 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Using a Routing Protocol over the VPN The VPN tunnel is now the wire. –Same benefits as a traditional WAN –Same bandwidth and delay considerations With a routing protocol, you can verify that traffic is actually reaching its destination.

10 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Example: Routing Protocol Two tunnels are active simultaneously.

11 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Anticipating Packet Fragmentation IPSec packet fragmentation is needed because IPSec/GRE exceeds MTU size. Fragmentation can dramatically affect head-end throughput performance. Use lookahead IPSec fragmentation features to resolve issues.

12 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v VPN Modes

13 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Example: Simple Site-to-Site VPN

14 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Example: Large Site-to-Site VPN

15 © 2004 Cisco Systems, Inc. All rights reserved. ARCH v Summary When designing the site-to-site VPN, you need to design the topology, and incorporate resiliency and failover mechanisms. When remote user or branch office connectivity is critical, downtime for the VPN is not an option. Enterprises need a systemic approach to examine all the essential elements of delivering a high-availability site-to-site VPN. A site-to-site VPN solution will support static routing and dynamic routing protocols that are implemented elsewhere in the network. IPSec and GRE headers increase the size of packets being transported over a VPN. You can implement site-to-site VPNs in both small and large enterprise environments.

16