The first management feature I'll focus on in this chapter is the concentrator's bandwidth management feature. Bandwidth management can be used to define bandwidth policies that affect site-to-site or remote access sessions, such as IPsec, L2TP, and PPTP connections.
Bandwidth management was first introduced in Version 3.6. One concern you might have with VPN sessions is that one group of users or a particular L2L session will use up all of your available bandwidth, leaving no bandwidth for other VPN sessions. Fortunately, bandwidth management allows you to create policies and apply them to your VPN sessions, so that you can prevent this problem.
Using bandwidth management is a two-step process:
Creating your bandwidth management policies
Activating your bandwidth management policies
The following two sections will discuss this two-step process.
Creating Bandwidth Policies
Cisco supports two types of bandwidth policies:
Bandwidth reservation reserves a minimum amount of bandwidth for an L2L or remote access session. This policy type typically is used to ensure that certain users or L2L sessions can get a fair share of the available bandwidth, especially L2L sessions. In other words, your L2L sessions might need a certain amount of bandwidth and you don't want heavy-bandwidth remote access users, such as those with broadband access, to affect your L2L sessions adversely.
Bandwidth policing places limits on the maximum rate for tunneled traffic; traffic that exceeds the configured rates is dropped by the concentrator. This policy type typically is used when you want to ensure that a particular L2L session or group of users (like those with broadband connections) don't hog all of the bandwidth on a particular interface on which their VPN session terminates.
One of your first tasks in setting up bandwidth management is to create your bandwidth policies. Typically, you'll create three types of bandwidth policies:
To create a bandwidth policy, go to Configuration > Policy Management > Traffic Management > Bandwidth Polices. This screen lists your existing policies. To add a policy, click the Add button, taking you to the screen in Figure 10-1.
Figure 10-1. Bandwidth Policy Creation
At the top of the screen you need to enter a name for your policy in the Policy Name text box. I typically use descriptive names. For example, if I'm creating a general bandwidth policy for tunneled traffic on the public interface, I would call the policy "General BW Public Policy" (or something like that). Likewise, if I were creating a bandwidth policy for an L2L session, I would use the L2L session name for the policy; if the L2L session was connecting my site to the Oviedo site, I would call the policy something like "Oviedo L2L BW policy." The actual policy name can be 32 characters in length.
Below this parameter are two sections for the two types of policies:
You'll notice that there is a check box to the left of each section name. This means you can configure bandwidth reservation and policing in the same policy or you could easily configure just one of the two, depending on the type of user or L2L traffic you are dealing with. The details of both are discussed in the following sections.
If your policy needs bandwidth reservation, click the check box to the left of Bandwidth Reservation. Below this is the Minimum Bandwidth parameter. This parameter allows you to specify a minimum amount of bandwidth available for each VPN session that uses the policy. For an L2L session, this policy would apply to all traffic traversing the associated tunnel. For a remote access group, this policy would apply to each individual user session associated with the group. As an example of using bandwidth reservation, if you set the minimum bandwidth value to 56 Kbps and this policy was applied to a remote access group, and 20 users from this group simultaneously accessed the concentrator, each user would be guaranteed 56 Kbps of bandwidth at a minimum, or 1,120 Kbps in total bandwidth. The default value for bandwidth reservation is 56 Kbps. You can specify a traffic rate from 8,000 bps up to 100 Mbps.
Take care when using bandwidth reservation. As you will see in the "Activating Bandwidth Policies" section, one of the things you specify for your concentrator's interface is its maximum supported link rate. For example, if your Internet connection was a T1, then even though your concentrator's public interface might support 100 Mbps, its true link rate really would be that of the external T1: 1,544 Kbps. Assume your default bandwidth reservation policy for the public interface was 56 Kbps. Given this policy, only 27 users would be able to connect to the concentrator given the guaranteed 56 Kbps of bandwidth reserved for each user and a total capacity of 1,544 Kbps. This is true even if the users are not using their reserved bandwidth! When the first user connects, she is reserved 56Kbps, but can use more bandwidth if needed. Once the second user connects, he also is reserved 56 Kbps. At this point, 112 Kbps of bandwidth is reserved for the two users, and the two users can use the remaining bandwidth of 1,432 Kbps (1,544 112). This process keeps occurring for each user who establishes a remote access connection. Once the 28th user attempts to establish a connection, the concentrator assumes that given a link capacity of 1,544, this additional user can't be supported because the concentrator already has reserved 1,544 kbps of bandwidth for the first 27 users. Therefore, I would use bandwidth reservation on a very limited basis, such as for an L2L session where you need to ensure that remote access users don't use up your available bandwidth and starve your L2L sessions.
Bandwidth policing is more suitable for remote access users when you want to limit the amount of bandwidth they can use. Any traffic sent above the policing rate automatically is dropped by the concentrator. When using bandwidth policing for remote access users, you are ensuring that one or more users don't use up bandwidth that might be required for certain L2L sessions or other remote access groups. If you're concerned that a group of users at least receives a minimal amount of bandwidth, but doesn't starve other VPN sessions, you can combine policing with reservation.
To create a bandwidth policing policy, click the check box to the left of Policing in Figure 10-1. Because data traffic is bursty in nature, policing involves the configuration of two parameters:
The best way to look at these parameters is from a Frame Relay perspective, where the Policing Rate parameter is similar to the committed information rate (CIR) and the Normal Burst Size is similar to Frame Relay's committed burst rate (BC). To set the burst size correctly, use the following formula: Normal Burst Size = (Policing Rate / 8)* 1.5. Policing Rate is measured in bits per second, whereas the Normal Burst Size is bytes per second, which is why the formula divides the policing rate by 8.
As an example, if you wanted to limit users to 128 Kbps of bandwidth, set the Policing Rate to 128 Kbps and the Normal Burst Size to 24 Kbps.
When you have finished adding your bandwidth policy, click the Add button at the bottom of the screen; if you're modifying an existing policy, click the Modify button.
Activating Bandwidth Policies
Once you have created your bandwidth policies, activate them for the policies to take effect. Bandwidth policies can be applied to one of three items:
The following sections discuss how to associate a bandwidth policy to each of the above three items.
Bandwidth Policies: Interfaces
Bandwidth management must first be enabled on the interface on which your VPN sessions will terminate; this is typically the concentrator's public interface. To use bandwidth management, the concentrator requires you first to enable bandwidth management on the interface where your VPN tunnels terminate and then to apply a general bandwidth management policy that will affect all VPN traffic terminated on this interface. As you will see in the next two sections, though, you can create specific bandwidth policies and apply them to remote access groups or L2L sessions: these override the general bandwidth policy applied to the concentrator's interface.
Per my explanation in the last section, you'll first need to create a general policy for the concentrator's interface for VPN traffic not associated with a specific bandwidth policy. Normally, this interface policy uses bandwidth policing, not reservation. Once you have created a policy for the interface, you'll need to enable bandwidth management and activate this general policy. Normally this is done on the concentrator's public interface, where most, if not all, of your VPN sessions are terminated. However, if you have a three-interface concentrator and are terminating sessions on the external and public interfaces and want to use bandwidth management on both, you'll need to create a general policy for both (if the policy requirements are different) and enable these on both interfaces.
To activate your general bandwidth policy, go to Configuration > Interfaces and click the hyperlink of the interface on which your VPN tunnels will terminate. Then click the Bandwidth tab at the top of the interface screen, presenting you with the screen shown in Figure 10-2. To enable bandwidth management, click the Bandwidth Management check box.
Figure 10-2. Bandwidth Policies and Interfaces
The Link Rate parameter specifies the true bandwidth available off of the interface. Even though the interface supports up to 100 Mbps speeds, this doesn't represent its true bandwidth. For example, if the concentrator were connected to a cable modem, then its effective available bandwidth would be between 1 and 5 Mbps. Or, if the concentrator was connected to a router, and the router had a T1 connection to the public network, the effective bandwidth would be 1,544 Kbps. The Link Rate parameter is used by the concentrator when you have enabled bandwidth reservation policies.
Below the Link Rate parameter is where you select the general bandwidth policy that should be applied to the interface. The Bandwidth Policy parameter is a drop-down selector that allows you to choose a policy for the interface. This policy is used for all VPN sessions terminated on this interface that are not associated with a specific bandwidth policy (one applied to a group or an L2L session). When you have finished selecting your policy, click the Apply button at the bottom to activate your bandwidth management changes.
Please note that bandwidth management policies apply to traffic both entering and leaving the concentrator's interface. To view your bandwidth management statistics, you can go to the Monitoring > Statistics > Bandwidth Management screen; this screen displays global statistics regarding bandwidth management. From the Monitoring > Sessions screen, you can view the bandwidth management statistics on a session-by-session basis by clicking the hyperlink of each individual VPN session name.
Bandwidth Policies: Remote Access Sessions
As I mentioned in the last section, the bandwidth policy applied to an interface is applied to all VPN traffic on the interface unless you override it. There are two ways of overriding the general policy: create a bandwidth policy and apply it either to a remote access group or to an L2L session. This section will discuss how you would associate a bandwidth policy with a remote access group; the following section discusses how you would do this for an L2L session.
One of the main concerns you'll have with remote access users, especially broadband users, is to ensure that their traffic doesn't consume the available bandwidth of the concentrator's effective bandwidth on its public interface. Remember that bandwidth management enforces policies in both directions on the interface, and most traffic is coming from the inside service or resource to the user. Therefore, most policies that you would create for remote access users would be bandwidth policing.
I already have discussed how to create bandwidth policies in the "Creating Bandwidth Policies" section. Once you have created a policy for a group of users, you can then apply it to the remote access group the users belong to. Do this by going to the Configuration > User Management > Groups screen. This was shown previously in Figure 7-2 in Chapter 7. To apply a bandwidth policy to a group, click the name of the group on this screen and then click the Bandwidth Assignment button (in version 3.6, this is the Assign Bandwidth Policies button).
You are taken to a screen where the concentrator's interfaces are listed as hyperlinks. Click the name of the interface where the remote access users for this group will terminate their VPN sessions (this is typically the public interface), which takes you to the screen shown in Figure 10-3. This screen allows you to choose the bandwidth policy that will be applied to this group. Choose the group's bandwidth policy with the Policy drop-down selectorthe drop-down selector lists the policies you have created previously.
Figure 10-3. Bandwidth Policies and Groups
For a group (or an L2L session) to use bandwidth reservation, the general policy applied to the interface must also have bandwidth reservation configured. This can be accomplished by specifying a bandwidth reservation of 8,000 bps for the general policy, which is the smallest value allowedright now, there is no way of getting around this restriction.
The second parameter you can configure on the screen in Figure 10-3 is Bandwidth Aggregation. I'll use an example that illustrates the usefulness of this parameter. Assume that you have a general bandwidth policy applied to the concentrator's public interface that has a reservation policy of 56 Kbps per VPN session and a reservation policy for a group, called Accounting, of 168 Kbps. The public interface has a link rate of 1,544 Kbps. A user establishes a VPN session to the concentrator and is associated with a group with no bandwidth management policy; therefore, the interface's policy is used and the user is reserved 56 Kbps, but has access to the remaining bandwidth on the interface (1,488 Kbps). Another user, from the Accounting group, then establishes a VPN connection to the concentrator and is reserved 168 Kbps of bandwidth. As more and more users of each type connect to the concentrator, they are reserved their assigned bandwidth until the concentrator reaches the rate limit of its interface; and then it drops any new connection attempts.
One of the problems in this scenario is that if enough users from groups other than Accounting connect to the concentrator, even a single user from the Accounting group might be rejected from connecting if the Accounting user's reserved rate value would cause the concentrator to exceed the rate limit of the interface. The function of the Bandwidth Aggregation parameter in Figure 10-3 is to reserve a specified amount of bandwidth for the group itself, ensuring that at least some users from the associated group can connect. Users using the general policy or from other groups cannot use this bandwidth; it's reserved for users of this group. For example, if the Bandwidth Aggregation parameter was set to 512 kbps for the Accounting group, at least three Accounting users would be guaranteed a connection to the concentrator, because this bandwidth would be reserved for the Accounting users. Then, in our example, users from any other group (including Accounting) would have access to the remaining 1,032 kbps of bandwidth.
Bandwidth Policies: L2L Sessions
Besides applying bandwidth policies to remote access groups, you can also apply them to L2L sessions. Once you have created your bandwidth policy for your L2L session, you can apply it by either going to the group screen or to the L2L screen. For the latter, go to the Configuration > Tunneling and Security > IPsec > LAN-to-LAN and click the Modify button. Then use the Bandwidth Policy drop-down selector to associate the policy to the L2L session.
Please note that if you assign a bandwidth reservation policy to an L2L session, the concentrator automatically sets the Bandwidth Aggregation value to match the bandwidth reservation value, ensuring that the L2L connection is guaranteed its reserved bandwidth whether or not the L2L session is currently up. Also, any bandwidth policies applied to the L2L session apply to all traffic that traverses the L2L session.
Bandwidth Management and QoS
Remember that the concentrator's bandwidth management feature implements a very basic quality of service (QoS) function. One limitation of this feature is that bandwidth management is applied to all traffic entering or leaving an interface, all traffic for a group (or users in a group), or individual L2L sessions. Unfortunately, you can't implement bandwidth management at the connection level. For example, if you had an L2L session with both voice and data traffic traversing it, you couldn't have two policies applied for the two types of traffic because they would be using the same tunnel session. If you had this particular situation, and needed to have different QoS policies for the two types of traffic using the same tunnel session, your best solution would be to use a Cisco router.