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

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.

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.