Defining Network Policies

Policy-based networking is a recent approach to network configuration that transcends the traditional command line by converting business-related policies into network-configurable commands. The technology underlying the policies is generally nothing new: access lists, queuing mechanisms, and network protocols.

However, policy-based networking adds a level of abstraction to the typical command-line approach to configuration. It involves describing a policy in a human-readable form and using network management software to translate the policy into router and switch commands.

The strength of this approach is the capability to define a central set of policies and distribute them to affected routers and switches. It eliminates some of the complexity and chance of error involved in managing configurations on a device-by-device basis. Policy-based networking also hides implementation differences between different devices.

As an example, let's say you want to implement QoS in your network. For all user switch ports, you want to set the IP type of service (ToS) field to equal zero by default. Zero is the lowest ToS value and thus will be treated with the least priority in a QoS enabled network. This is to protect against users that try to increase the ToS field for traffic coming from their workstation.

So the written policy may read as follows:

For all switched user ports, assign lowest priority to traffic by default.

However, to implement this policy, different commands must be given, depending on what type of Catalyst switch is to be configured. It means setting the ToS equal to zero for all IP packets. Also, you will need to know which ports are considered "user ports." What applications will cause the ToS to be set to something other than zero?

Understanding the components that make up a policy is the key to writing clear, configurable policies. A policy describes an expectation from a part of the business. You must learn the business needs that drive the success of the network.

Communication and Network Policies

When articulating policies, you should do so from the user or network consumer's point of view. Latency, utilization, and response times mean very little to non-network personnel. From their perspective, an application must be available when they need it and at a speed that does not hinder their ability to do their work.

For most companies, business requirements are vague or unspecified. The expectation may simply be that the network "runs" whenever somebody wants it. In this case, you should determine what you feel accurately reflects their needs. Doing so will help lead toward stronger policies that can then be reflected in service level agreements, which will be discussed later in this chapter.

Importance of Open Communication with Users

When you set expectations honestly and in layman's terms, your user community will better understand what to expect from the network and any limitations that may occur due to the current network design.

For instance, suppose that your user community considers a particular application business-critical and requires that it be available 24 hours a day, seven days a week. However, when conducting a network audit (as described in Chapter 1, "Conducting a Network Audit"), you discover that certain key connectivity points to the application's server contain no redundancy. You feel that with the current design you cannot reliably deliver around-the-clock availability.

Rather than hoping that the network doesn't break, it is better to communicate the network vulnerability and present alternatives. This communication enables you to argue effectively that better service requires a larger budget and empowers your users by helping them understand the very real business issues.

Converting Policies into Technologies

After you collect the user community needs, you must convert them into distinct policies that together describe the network portion of the business requirement. Although the policies should be written in layman's terms, the actual elements that make up the policy should be written as concrete, measurable data that can be collected.

Part of the policy is to identify the configuration changes that must take place in order to condition the network to implement the policy. Although outside the scope of this book, configuration changes include the commands that must be run to implement a particular technology, such as QoS or encryption. The value of policy-based configuration software is its capability to let you define a policy that translates into configuration changes on affected devices.

The other part of defining policies is identifying the data that can be used to verify successful and effective policy implementation. This is the process of identifying the collectable data that will reflect your policy, such as SNMP variables and show commands. What can you measure and report on that reflects the success or failure of the business requirements? What data can you observe that will allow you to spot a policy-violating problem before or as it happens? How do you know that a newly configured policy actually does the job?

The network management must be designed to report on the appropriate information that allows the detection of policy violations or failures when they occur. Configuring, enforcing, and reporting network-related information in terms of business policies is the art of the network manager, and, frankly, what makes network management interesting.

Suggesting policies that don't reflect the true nature of what the network can deliver will only result in improperly set expectations. A baseline analysis of your current network will help you determine how to draft effective policies, given your current network performance.