Using Policy-Based Management: An Example

This section uses an example network scenario to illustrate the components of defining network policies and conducting a network baseline.

In this example, you are responsible for a 600-site network that connects all of your company's sales and customer service offices to the corporate backbone. You grew weary of various business heads knocking on your door every time they perceive what they think is a network problem. To address the problem, you decided to talk with different parts of the company and identify networking requirements.

You begin by talking to the various business heads that have an interest in how the network operates for the remote sales locations. They include the following:

• Marketing Who depends on the network for distributing product materials and pricing in a timely manner.

• Accounting Who must have up-to-the-minute access to sales data.

• Sales Who require speedy and guaranteed access to the order entry system. Because delays in booking orders affect the corporation's bottom line, they must be minimized.

• Manufacturing Who forecasts its production based on booked sales and thus needs timely access to the numbers.

• IS telecom Who roll out IP telephones to the remote sites over the traditional data network. Delays over 150ms are unacceptable for voice over IP.

• IS applications development Who is responsible for the home grown applications that the sales force uses.

Drafting the Policies

After talking with all of the interested parties, you draft policies that capture the expected requirements. Examples include the following:

• The sales order application must be available 24 hours a day, seven days a week.

• The Ethernet phones require that voice traffic experience no more than 150ms latency across the WAN.

• The network must be up and available 99.98 percent of the time, according to your CIO. (You are not sure how she arrived at that number, but for political reasons you must adhere to it.)

• Non-critical traffic must be restricted during normal business hours at each sales office in order to keep the lines clear for voice and data transactions. This includes any game-playing, data backups, file transfers, or database syncs.

When collecting requirements, you also must attach costs to improving the network in order to deliver the levels of service people ask for. Non-IT executives tend to forget that there is a cost associated with guarantees.

Consider the first list item as an example: The sales order application must be available 24 hours a day, seven days a week. The network is a key component to the execution of this policy. The phrase "the network is the computer" holds more truth than ever.

In order to provide 24x7 access, the server that the application runs on must be accessible all the time. You walk over and talk to the group that administers the server and they have decided to run two machines redundantly; the second takes over if the first fails. This means that there must be two network connections and the devices must run HSRP. Notice that the discussion of service-level guarantees leads toward network design issues.

Next question: Which users use the application and where are they located? The sales people use the application and they are located all over the world. Some will use the application from their sales office, which is connected back to corporate via Frame Relay. Others dial in from home to run the application.

The VP of sales has sent a note to the CIO (your boss's boss) indicating that the sales order application is business-critical, and that the company loses $20 million in unbooked revenue for every hour this application is unavailable. In her words, this application is absolutely critical to the bottom-line success of the company and its stock. Usually, this type of statement is grandstanding, but you will need to present the cost of achieving the desired level so that the VP can make an informed business decision.

Your boss has come to you and asked that you put together some monthly reports that can be viewed by the interested business leaders across the company. These reports must demonstrate that the network is doing what you have promised. And, oh, by the way, you must identify network criteria by which your boss can evaluate you when determining your annual bonus.

All in all, there will need to be a meeting of the minds to agree on a final set of policies and SLAs. Some of what is asked for is unachievable. You will need to be prepared to defend a budget that you consider necessary for implementing what they ask.

Conducting the Baseline Analysis

First, you must conduct the baseline you've been avoiding since you took this job. Based on the policies you crafted, you determine that the baseline should last four weeks and will be conducted against all remote sites.

You also decide that the following data should be collected:

• Router availability

• WAN interface utilization

• WAN response time

You install and configure a set of baseline collection and reporting tools. In this case, MRTG will do the job nicely (see the References at the end of this chapter for more information on MRTG). Initially, you try a dry run for a couple of days to make sure that the collection is configured correctly and the data is useful, and then finally kick off the actual baseline.

During the collection period, you look at some of the data and play with the reporting. This allows you to set up reports that provide the information needed to document the baseline. It also allows you to identify troublespots that may get in the way of delivering your policies.

After the baseline is complete, you look at the "Top 10" reports that identify the worst response times, worst availability, and worst utilization. The response times look pretty good, but the availability looks terrible. On average, the availability of WAN links was 96.6 percent, a far cry from the expected 99.8 percent expectation. You plan to look deeper into the causes of these outages.

Also, the "Top 10" interface utilization reports reveal that more than 15 percent of the sites are experiencing heavy load in excess of 90 percent most of the business day. You will need to study the interfaces closer in order to determine whether traffic is being dropped and if customers are noticing delays.

For the sake of this example, after subsequent analysis, you determine that a network redesign is necessary in order to meet the corporate requirements. In this case, you decide to run redundant Frame Relay connections back to each remote office to form a dual regional star topology. In addition, you plan to review the SLAs you have with your telco providers. If there are no SLAs, you need to get one.

You make a business case for the additional cost using the baseline study data, and hopefully the sales organization agrees to fund the effort.

Meanwhile, it's time to empower your customers. You determine that the best way to please your customers month after month is to clearly articulate the service levels they can receive from the network. You must negotiate levels of service and consequences when they are not met, have your customers agree to the service levels, and provide reports that demonstrate the network's actual delivery of the service levels. In addition, rewards in the form of quarterly bonuses are given to the IT staff for meeting or exceeding the SLAs.

Charting the SLA

By setting expectations up front and communicating how well the network meets those expectations, you eliminate finger pointing and instead shift the focus to a cooperative, measurable agreement.

You draft an SLA that specifies the following:

• A restatement of customer expectations in non-networking terms

• An explanation of how the expectations translate into the data that will be used for reporting the service level adherence

• Details of the types of reports that will be used, how they will be distributed, and how frequently they will be updated

• Agreed-upon terms that identify the penalties and resolution to unmet service levels

You decide to publish the reports on the Web, thereby making the service level reporting accessible all the time and by whomever needs to view the reports. Business heads can view the data whenever they want, and you have clearly documented and agreed-upon service levels that drive your design.

Although this is a simplified example, you can see how communication and agreement on operating levels make your job easier and raise the satisfaction of your customers.