Solaris Bandwidth Manager 1.5 Administration Guide

Chapter 3 Planning

Bandwidth management must be planned for your whole network, not for individual points where the software runs.

There are two stages to planning bandwidth management:

Deciding where to install Solaris Bandwidth Manager
Deciding how to configure Solaris Bandwidth Manager at each point where it is installed

Where to Use Solaris Bandwidth Manager

Use Solaris Bandwidth Manager at any point in your network where the demand for bandwidth sometimes or always exceeds what is available, and at potential bottlenecks in your network such as the start of a transatlantic or other long-distance link or a LAN/WAN border. Solaris Bandwidth Manager regulates incoming and outgoing traffic. If a network link uses a shared medium, you must regulate traffic at all points that send traffic over the link.

Solaris Bandwidth Manager can be used on a host that is a source of IP traffic, on an IP router, or on a host that is between a LAN and a router (known as running in IP-transparent mode, as described in "IP-Transparent Mode ").

Note -

You cannot use Solaris Bandwidth Manager to regulate traffic flow on a logical interface, such as le0:1. However, by defining classes that correspond to the traffic that would use a logical interface, you can achieve the same result. See "Logical Interfaces" for an example of how to do this.

Solaris Bandwidth Manager regulates incoming and outgoing traffic at a given point in your network. Depending on your network topology, it might be useful to use bandwidth allocation at a point before any known bottleneck.

Figure 3-1 Planning Where to Use Bandwidth Manager

Assume you have the network shown in Figure 3-1, with the link capacities (in arbitrary units) shown.

If host C does not generate any traffic, it is not necessary to use Solaris Bandwidth Manager, since the capacity of link CD is sufficient for the total amount of traffic that both AC and BC can deliver at a given time. However, if host C is also a source of traffic, use Solaris Bandwidth Manager at C to regulate the flow of traffic on the link CD.

If the capacity of the link AC is increased to 10, host C becomes a potential bottleneck, whether or not it is a source of traffic itself, since the total amount of traffic that AC and BC together can deliver at a given time exceeds the capacity of CD. Using Solaris Bandwidth Manager at C does not prevent this. Instead, you need to run Solaris Bandwidth Manager at A, preventing, or reducing the probability of C being overloaded. If C is not a source of traffic, using Solaris Bandwidth Manager at A alone is probably sufficient. If C is a source of traffic, use Solaris Bandwidth Manager at A and C.

When planning the configuration of Solaris Bandwidth Manager at a point in your network, you must consider the configurations of other bandwidth managers upstream in the traffic flow. For example, if at A, the ftp-from-A class is configured to use no more than 2 units of capacity of AC, there is no point in giving the ftp-from-A class more than 2 units of capacity of CD.

You must also be careful not to set the traffic limits too low and underuse a link. Configure Solaris Bandwidth Manager across your network so that all links are fully used, and use the relative priorities of the classes to determine which packets are dropped or delayed if a link is busy.

In planning where to install Solaris Bandwidth Manager, you need to consider the characteristics of particular types of traffic. With HTTP traffic, for example, the heavier traffic flow is towards the user who instigates the transfer, so it is more useful to use bandwidth management on a web server than on the user's local machine.

Configuration Planning

At each point where you plan to use Solaris Bandwidth Manager, you must decide the following:

Whether to use IP-transparent or server mode. See "Solaris Bandwidth Manager Modes" for explanations of these modes.
How multicast traffic is handled, if you are using IP-transparent mode. See "Multicast Routing and Solaris Bandwidth Manager".
The hierarchy of classes, and the priority and bandwidth allocated to each class. See "Designing the Class Hierarchy" and "Allocating Bandwidth".
How to specify groups, filters, and services to construct the classes you require.

There are no precise rules for choosing an initial configuration for Solaris Bandwidth Manager at a site. You could start with a configuration that reflects the actual usage patterns, perhaps adjusted to solve any serious problems, monitor the performance over a period and fine-tune the configuration. Alternatively, you could start by allocating equal bandwidth to all classes, and running Solaris Bandwidth Manager in stats mode to monitor how traffic is classified before allocating real bandwidth percentages to classes.

Designing the Class Hierarchy

The class hierarchy must be based on the network traffic patterns that you want to establish for a link. As a starting point, consider the actual traffic patterns. "Configuration Planning Example" explains how information about current traffic patterns can be used to create the class hierarchy.

The class hierarchy does not need to be the same at every point, but you need to be aware of how the classes at one point correspond to the classes at other points down the route of a packet.

You must also take into account the characteristics of the traffic in each class, and how you can define a class. For example, some applications allocate port numbers dynamically. Since you do not know the port number in advance in these cases, defining a class on the basis of port number for traffic generated by such applications is not useful. Instead, use the protocol and address information to define these classes.

Allocating Bandwidth

Guaranteed minimum bandwidth is allocated in percentages or in bits per second. The root class has 100% of the bandwidth configured for an interface. Each child class of the root class is allocated a share of root's bandwidth. The child classes of those classes are allocated a share of their parent's bandwidth. The bandwidth you allocate is the minimum guaranteed bandwidth for a particular class. You can also set a ceiling, or maximum bandwidth if you want.

The rest of this section is an example of how to allocate bandwidth to a hierarchy of classes. Assume you have the following class hierarchy:

Figure 3-2 Example of Allocating Bandwidth: Class Hierarchy

Before you allocate any bandwidth to child classes, the root class has 100%:

Figure 3-3 Example of Allocating Bandwidth: Root Allocated 100%

Share the bandwidth allocated to the root class with the child classes of the root class, 1, 2, and 3:

Figure 3-4 Example of Allocating Bandwidth: Child Classes of Root

The root class itself requires some bandwidth to handle traffic allocated to it, therefore, do not allocate 100% of the bandwidth to the child classes. The root class will use the 5% that is left.

For each child class, share the bandwidth allocated with their own child classes. For example, share the 30% allocated to class 1 with child classes 1.1 and 1.2. The figure in brackets shows the amount of bandwidth left-over once you have allocated bandwidth to the child classes. This left-over bandwidth effectively becomes the guaranteed minimum bandwidth for the parent class.

Figure 3-5 Example of Allocating Bandwidth: Second Level Classes

Continue sharing the bandwidth allocated to each class with its child classes until all classes have an allocation:

Figure 3-6 Example of Allocating Bandwidth: Allocation Complete

Note -

When specifying the bandwidth allocated to a class in the configuration file or using batool, you must specify the aggregate bandwidth allocated to a class and all its descendants. For example, for class 3.1, specify 20%, and for class 1, specify 30%.

Borrowing Bandwidth

When using bandwidth allocation, every class has a guaranteed minimum bandwidth. However, if the amount of traffic in that class exceeds the bandwidth allocated, and if there is "spare" bandwidth that is not being used by another class, the class can borrow bandwidth.

In the above configuration, assume that traffic for class 1.2 exceeds the 5% allocated. Assume that it is 7%. But traffic in class 1 overall only adds up to 20%, leaving 10% of class 1's aggregate bandwidth available for borrowing. Class 1.2 can borrow up to 10% from class 1, so in this case, it can borrow the 2% it needs.

However, a class cannot borrow at the expense of another class's guaranteed minimum bandwidth. Assume that traffic in class 1.2 remains at 7%. But traffic in class 1.1 increases to 15% and traffic in class 1 overall increases to 30%. Class 1.2 cannot go on borrowing from its parent class, class 1. It may be possible for class 1 to borrow from its parent class root. In this case, class 1.2 could then borrow this extra bandwidth from class 1.

When more than one class wants to borrow bandwidth, the class's priorities are used to decide which class can borrow. The class with the highest priority can borrow all than bandwidth that it needs (subject to availability). If there is any bandwidth left, the next highest priority class can borrow, and so on.

If more than one class of the same priority wants to borrow, the amount of minimum guaranteed bandwidth is used to decide. For example, if classes 1.1 and 1.2 both wanted to borrow, and both had the same priority, a ratio of 3:1 would be used to split the available bandwidth between them.

Note -

In order to prevent a high priority class from using up all available bandwidth at the expense of other classes:

Make sure you allocate a sufficient level of guaranteed minimum bandwidth to all classes in the configuration.
Consider configuring a maximum level of allowed bandwidth for high priority classes.

Configuration Planning Example

This section contains an example of bandwidth management being used within the European network of the Example Corporation, at three points: Paris, Bonn, and London.

In the example, the Paris and Bonn sites each have a busy LAN, and route traffic from the LAN and from other sites on to the London site. From Paris to London there is a 256K line. From Bonn to London there is a 768K line. There is also a dial-up link directly from Paris to Bonn. London has its own LAN, and routes traffic from it and from Paris and Bonn to a site in the USA over a 10Mb line.

Figure 3-7 Bandwidth Allocation Planning for the Example Corporation

At all three sites, the network administrator monitored the actual network usage over a period, and asked users what they thought were the three most important uses of the network. The following sections contain the data for each site and show the configuration that was designed.

Paris

Figure 3-8 Actual Network Use for Paris Site

The network users at the Paris site consider e-mail, file transfer and access to the world wide web to be the most important uses of the network. The actual usage pattern is shown in Figure 3-8.

Using the data on network use and the user input, the network administrator designed the class hierarchy shown in Figure 3-9 and assigned the priorities and percentages of bandwidth shown in Table 3-1.

Figure 3-9 Class Structure for Paris Site

Table 3-1 Bandwidth Allocation and Priority of Classes on Paris Server


Class Description	Class Name	Parent Class	Percentage of Bandwidth Allocated	Priority
Root	root		100	1
http to Bonn	http-bonn	http	5	3
http to London or US	http-lon	http	10	3
http to elsewhere	http	root	20	5
telnet	telnet	root	30	1
System monitoring	snmp	root	5	1
e-mail	email	root	20	4
File transfer	ftp	root	15	7
Default	default	root	5	7

In batool and in the configuration file, you must specify the bandwidth allocated to a class and all its descendants. For example, the http-bonn and http-lon classes are both child classes of the http class. The http class and its decendents are allocated 20% of the bandwidth, of which the child classes are allocated allocated 5% and 10%.

With this configuration, the bandwidth used by FTP traffic is constrained to 15%, contrasting with the current usage figure of over 30%

Bonn

Figure 3-10 Actual Network Use for Bonn Site

The network users at the Bonn site consider order administration, e-mail and calendar access to be the most important uses of the network. The order administration system uses HTTP to transfer data. The actual usage pattern is shown in Figure 3-10.

Using the data on network use and the user input, the network administrator designed the class hierarchy shown in Figure 3-11 and assigned the priorities and percentages of bandwidth shown in Table 3-2.

Figure 3-11 Class Structure for Bonn Site

Table 3-2 Bandwidth Allocation and Priority of Classes on Bonn Server


Class Description	Class Name	Parent Class	Percentage of Bandwidth Allocated	Priority
Root	root		100	1
http to Paris	http-paris	http	18	2
http to London or US	http-lon	http	18	2
http to elsewhere	http	root	40	2
e-mail	email	root	20	6
Telnet for system administration	telnet	sysadmin	8	1
SNMP	snmp	sysadmin	10	4
System administration	sysadmin	root	20	1
Default	default	root	10	7

London

Figure 3-12 Actual Network Use for London Site

The network users at the London site consider e-mail, calendar access, and file transfer to be the most important uses of the network. The actual usage pattern is shown in Figure 3-12.

To design the class hierarchy and assign the bandwidth and priority to the classes for the London site, it is necessary to consider the following:

The data on actual network use
Information about user preferences
The patterns in the traffic originating in Paris and Bonn, according to their own bandwidth management configurations
The difference in capacity of the links connecting Paris and Bonn to London (the Bonn to London link has three times the capacity of the Paris to London link).

Taking all this into account, the network administrator decided to run the Solaris Bandwidth Manager software on the host that runs the routing software, and designed the class hierarchy shown in Figure 3-13.

The classes shown in parentheses are not actual classes, but remind the network administrator to allow bandwidth in a parent class where the child classes do not account for all the traffic. In the http class, for example, there are two child classes, for traffic to the US and to Europe. There will also be http traffic that is not going to the US or Europe. This traffic will be allocated to the http class, so the percentage of bandwidth allocated to the http class should not all be shared between the child classes. Table 3-3 shows the percentage of bandwidth and the priority assigned to each class.

Figure 3-13 Class Structure for London Site

Table 3-3 Bandwidth Allocation and Priority of Classes on London Server


Class Description	Class Name	Parent Class	Percentage of Bandwidth Allocated	Priority
Root	root		100	1
http	http	root	35	4
http to US	http-to-US	http	20	2
http to US from Paris	http-Paris-to-US	http-to-US	4	4
http to US from Bonn	http-Bonn-to-US	http-to-US	10	2
http to US from UK	http-UK-to-US	http-to-US	4	4
http to Europe	http-to-europe	http	10	4
Electronic mail	email	root	30	3
e-mail from Paris	email-paris	email	5	3
e-mail from Paris (IMAP)	email-paris-imap	email-paris	4	3
e-mail from Paris (SMTP)	email-paris-smtp	email-paris	1	6
e-mail from Bonn	email-bonn	email	15	3
e-mail from Bonn (IMAP)	email-bonn-imap	email-bonn	12	3
e-mail from Bonn (SMTP)	email-bonn-smtp	email-bonn	3	5
e-mail using IMAP	email-imap	email	7	3
e-mail using SMTP	email-smtp	email	2	5
FTP	ftp	root	15	7
System administration	sysadmin	root	10	2
Telnet	telnet	sysadmin	5	1
System monitoring	snmp	sysadmin	2	2
From system admin console	administrator	sysadmin	2	1
Default	default	root	5	7

The percentage of bandwidth allocated to a class containing traffic originating in Paris or Bonn takes into account the differences in the link capacity between those sites and the London site. For example, the classes for e-mail from Bonn have three times the allocation of the classes for e-mail from Paris.