L2L Connectivity Example

To understand the components involved in an L2L session, I've created the diagram shown in Figure 9-1. This figure shows a simple example of a network using L2L sessions. In this example, a corporation has two redundant 3060 concentrators at the corporate site: ConcentratorA and ConcentratorB. These concentrators handle L2L sessions and many remote access sessions. Redundancy is set up between the concentrators. This chapter discusses L2L redundancy and in Chapter 10, "Concentrator Management," I'll discuss remote access redundancy.

Figure 9-1. L2L Example

The corporate network is using 172.16.0.0/16 for a network number, where this has been subnetted into many subnets. The regional offices in Orlando, Tampa, and Miami each have a 3030 concentrator. These concentrators each have an L2L session back to the redundant configuration at the corporate office. These concentrators also handle local remote access users. Because very little traffic flows between the regional offices, the network administrators decided to send all traffic through the corporate site; however, if traffic patterns change, an L2L session can easily be added between two regional sites.

All of the VPN 3000 concentrators support IPsec L2L sessions; however, not every concentrator has the same capabilities. Table 9-1 compares the number of simultaneous L2L sessions that each of the concentrators support. Remember from Chapter 6, "Concentrator Product Information," that L2L sessions count as a session against the total number of concurrent (L2L and remote access) sessions that a concentrator supports. For example, the 3080 supports 10,000 total sessions, of which no more than 1,000 of those can be L2L sessions.

Table 9-1. Concentrator L2L Session Restrictions

Models	Maximum L2L Sessions
3005	100
3015	100
3020	500
3030	500
3060	1,000
3080	1,000

Note

The only type of L2L session that Cisco concentrators support is an IPsec L2L session.

Platform Choices for L2L Sessions

Cisco has three platform choices for L2L sessions: concentrators, routers, and PIX and ASA security appliances. Each has its advantages and disadvantages. For example, configuring L2L sessions is a simple process on a concentrator. Plus, of the three solutions, I find it much easier to troubleshoot problems with the concentrator than the other two (I'll discuss the concentrator's troubleshooting capabilities in Chapter 11, "Verifying and Troubleshooting Concentrator Connections"). However, concentrators have the following disadvantages: Limited routing functions, limited QoS support (discussed in Chapter 10), and limited address translation support (discussed in the "Address Translation and L2L Connections" section later in the chapter).

PIX security appliances, on the other hand (at least in FOS 6.3 and earlier), must be fully meshed with L2L IPsec connections. They lack QoS: a hub-and-spoke topology fails because of the Adaptive Security Algorithm (ASA) rules of traffic entering and leaving the same interface. FOS 7.0 is required on the PIX and ASA to solve these problems. One problem remains with the PIX and ASA, though: they are a very poor routing platform. The main advantages of the PIX and ASA, however, are that they are extremely flexible in their address translation policy configuration and are built as a firewall solution, and thus are very good at filtering traffic.

The best solution for L2L sessions are Cisco routers: they have the best routing capabilities for L2L sessions (I'll discuss these in Chapter 17, "Router Site-to-Site Connections") and flexible QoS capabilities. Plus, routers have better address translation abilities than concentrators, but not better than the PIXs and ASAs. The biggest advantage of the routers, though, is that they can easily scale to a large number of L2L sessions with minimal configuration, which is not true of the concentrators and PIXs and ASAs.

Therefore, if I have a complicated, redundant design, I prefer to use routers over the other two solutions. For a simple nonredundant design, I'd use a concentrator, and less preferably, a PIX or ASA. I would use the PIX (assuming it was running 6.3 or earlier) only if QoS wasn't important and the PIX was a spoke device in a hub-and-spoke design. For advanced address translation capabilities and firewall capabilities, I would consider the PIX and ASA security appliances first above the other two.