Four-Step QoS Design Process

670 Chapter 9: Management Tools and QoS Design

Step 1: Determine Customer Priorities/QoS Policy

One of the hardest parts of the four-step process is to reach agreement about which traffic is important, and which is not. The “problem statement” in Step 1 presumes that you work for a vendor, or a reseller, or a consulting company, and you are helping a customer. Even if you are making QoS design choices for your own company, you need to involve the people who know the applications and the business priorities in the network, and not just the guys who operate and engineer the network.

You may need to hold planning sessions with representatives from many departments and divisions from the same company, or you may just get the most capable people together in one room and come up with a plan. Regardless of how formally or informally you attack the problem, you should finish the process with a set of general statements like the following:

•The traffic needs to be classified into five different categories.

•Category 1 should get 30 percent of the bandwidth, and have low delay and low jitter. It consists of voice traffic only. The delay budget is 150 ms maximum one-way delay.

•Category 2 should get 15 percent of the bandwidth, with moderate delay, and high jitter allowed. Loss can also be as high as needed. Web traffic to the customer server farm is placed in this category.

•And so on . . .

Statements with this level of detail provide you with a good idea of what needs to be implemented. However, you may not know exactly how to configure the parameters for each QoS tool based on this level of depth. For instance, you probably memorized the range of UDP port numbers used for VoIP traffic after reading this book, but most people simply do not memorize such trivia—so on to Step 2!

Step 2: Characterize the Network

Now you can send most of your fellow QoS policy planners back to their normal jobs, and start analyzing the network. In short, at this step, you should perform a network audit. The results of the audit should be that you have an understanding of how much traffic is occurring regularly in the network, and what QoS behavior they are experiencing in regards to bandwidth, delay, jitter, and loss. The audit should answer several questions, such as the following:

•How can I uniquely identify the packets that belong to each category defined in the QoS policies?

•How much bandwidth is currently being used by each application? By each QoS policy class?

•How have the bandwidth requirements been growing per application, and per class?

•What are the voice call traffic patterns? What are the busy hour statistics?

QoS Design for the Cisco QoS Exams 671

Although this list of questions is a short sample, the questions illustrate some of the general issues you must know before deploying QoS policies. If the policy calls for 15 percent of the link for Category 2, as stated earlier, but those packets currently consume 60 percent of an almost fully utilized link today, you need to reconsider the policy, consider increasing bandwidth, enable compression, and so on.

You have several tools at your disposal for performing the network audit. First, you can enable network-based application recognition (NBAR) to start gathering statistics and packet/ byte/bit rates, and information about the types of traffic running through the network. You can also enable NetFlow statistic gathering in Cisco routers, which is another IOS tool, similar

to NBAR, which gathers statistics for types of packets. With NetFlow, the statistics can be gathered to a server for historical reporting, which can be very helpful in this repetitive fourstep process. Finally, you can always plug in your favorite network analyzer, many of which provide statistics of types of packet flows as well as the typical packet capture and analysis used when troubleshooting.

At the end of this step, you should have the same list of categories from Step 1, but now with enough information about how to go configure the QoS tools. This includes a classification and marking strategy, with each class specified, and the corresponding DSCP or precedence value identified. You should now be ready to implement specific QoS tools at Step 3.

Step 3: Implement the Policy

During this step of the design process, you have two main subtasks:

1To implement the trust boundary by using classification and marking

2To choose and implement the tools that affect bandwidth, delay, jitter, and loss

Recall from Chapter 3, “Classification and Marking,” that you should attempt to mark the packet closest to the source of the packet. By doing so, all other QoS tools can more efficiently classify the packet based on its specific marking, such as the IP Precedence or IP DSCP fields. Of course, you must also choose a trust boundary—the boundary between the devices from which you can trust the precedence or DSCP values, and the devices that you cannot. Figure 9-4 may remind you of some of the typical choices for trust boundaries.

672 Chapter 9: Management Tools and QoS Design

Figure 9-4 QoS Trust Boundaries

Typically, at remote sites with no Layer 3 switching capabilities, you end up performing the classification and marking function on ingress to a WAN edge router. In larger campuses, classification and marking typically occur in a switch capable of performing Layer 3 marking. Marking can also occur in Cisco IP Phones.

Before implementing the rest of the QoS features, you need to decide which tools meet the requirements. For instance, you may have decided to shape traffic on WAN links, so you could use generic traffic shaping (GTS), class-based (CB) shaping, or Frame Relay traffic shaping (FRTS). If you use a Frame Relay WAN, and you want to perform FR fragmentation, however, you may have to use FRTS, because GTS and CB shaping do not allow FR fragmentation at the same time on all platforms. Therefore, you must next pick the tools that enable you to configure the defined policies.

Finally, you just need to configure the tools at the various points in the network. When completed, you need to know whether the configurations work, which brings you to Step 4.

Step 4: Monitor the Network

The monitoring step requires tools as well as effort. The tools have already been covered in this chapter—namely QDM, QPM, IPM, and SMS. With these tools, you can configure and monitor the network performance in real time and historically. However, creating reports is not enough— you must read them, interpret them, and begin the whole four-step process over again—at least if you want to do what is suggested by the DQOS course!