Policies and Procedure Definition
It is impossible to successfully manage routers without clear policies and procedures. The policies need to document who is responsible for various levels of management and when they are responsible. They need to document when changes can be made to router configurations. The procedures document how changes are made, including describing what changes are taking place and backout and testing procedures. The procedures specify steps to follow when a more skilled engineer needs to begin working on a problem and when management needs to get involved. It also is important to have a clear plan for disseminating updated policies and procedures so that everyone involved is aware of the changes.
Policies that specify the Quality of Service (QoS) the users can expect from the network should be in place, such as round-trip delay time, a minimum amount of throughput or the amount of network availability, along with the actions that will be taken if the service is not met. These are referred to as Service Level Agreements. This section describes Service Level Agreements, change management policies, escalation procedures, and the necessity of keeping the policies and procedures up to date.
Service Level Agreements
Service Level Agreements (SLAs) clearly define the quality and quantity of service that is to be provided, as well as when and by whom it will be provided. They specify quality, such as guaranteed response time and throughput, as well as maximum jitter. Quantity is expressed as a percentage of network availability. SLAs identify when the network will be available, the maximum amount of time for a single outage, scheduled outages, and who is providing the service. It is important to identify who is providing the service to avoid misconceptions about realms of responsibility. Avoid finger-pointing by defining which organizations are responsible for which network components and the level of service for which each organization is responsible. The SLA must be clearly defined so that both the organization providing the SLA and the organization receiving the SLA understand and agree on the contents. SLAs could be provided by outside organizations providing services to your business, such as ISPs or companies to which you are outsourcing your network. Or, they may be provided by internal IT departments providing service to business units within the company.
The most effective SLAs are written with business objectives in mind. Consider, for example, the following SLA statements:
Round-trip delay is less then 50ms, averaged over 1 hour, from site A to site B. Link availability is no less than 95%.
These SLA statements are not very useful if the business objectives require 99.9999% availability but do not need anything faster than 400ms round-trip delay. Any provider that is offering specialized QoS to particular applications, end stations, or sites will include the guaranteed level of QoS in an SLA.
An SLA does not provide any benefit if the service is not monitored. The provider guaranteeing the QoS in the SLA will need to verify that the user or application is indeed receiving that QoS. An SLA that provides end-to-end guarantees must be monitored end to end. An SLA that states the following:
Round-trip delay is less than 200ms, averaged over 1 hour, from users at site A to servers at site B.
is measured differently from one that states the following:
Round-trip delay is less than 100ms, averaged over 1 hour, from site border routers at site A to site border routers at site B.
Both statements may be included in a service level contract, and both should be monitored. The collected data is reported to both the service provider and the service users. Both need to read the reports to verify the SLA has been satisfied.
Change Management
A network without change management policies is likely to be a network in chaos. Change management policies state when changes can be made, who can make them, how to document and publish upcoming changes, and how and where to document completed changes.
The change management policy specifies the procedure to use when any network or system change is going to take place. This includes router configuration changes, new design implementations, IOS upgrades, or even the implementation of new network applications. There should be an electronic form to fill out with some or all of the following information:
Who is requesting the change Why the change is being made What is the impact of the change (nondisruptive, maybe disruptive, disruptive) When will the change take place How long will it take to make the change How long will the change remain in effect What test procedures have been accomplished to test the change about to take place Who performed the tests Who will perform the change What are the procedures to perform the change What are the post-change test procedures to verify the change was successful What are the backout procedures
A change control board (CCB) may look at all upcoming changes for any given week and approve or disapprove changes. The CCB should include a knowledgeable representative from each group that designs, operates, maintains, and manages the network. It also should include a representative for each group that uses the network, such as the various business units within an organization. If the network is an ISP, the network user representative may be a customer service representative, responsible for the well-being of groups of customers. The CCB review process ensures that all network architects, operators, administrators, managers and customer support personnel, and network users are aware of planned activities, know of potential impacts, and have an opportunity to consider other mitigating factors before changes are applied.
The requested change must be approved by all members of the CCB and signed by all relevant parties, indicating that they are aware of the change and potential risks.
Sometimes an emergency change is required—to solve a problem, for instance. The change policy also specifies what to do in the case of an emergency. The policy specifies who can make emergency changes, under what circumstances, and how to document the changes.
It is very important to document all changes. A table identifying when a change was made, what change was made, who made it, and a reference to the change description document (such as the sample shown in Table 9-1) enables someone to go back and know what changed, in the event of a future network or router problem.
Table 9-1. Change Policy Management Documentation|
| 6/3/00, 1:00 a.m.
| Modified BGP peer on router Taos
| Joe Smith
| No
| Pluto:changes\RtrTaos060300
| | 5/27/00, 1:00 a.m.
| Enabled custom queuing on router Aspen, on link to site Denver
| Jane Anders
| No
| Pluto:changes\RtrAspen052700
|
If someone at site Denver calls the network operations center to report a problem with his connections to remote sites, and he says that the problems were first noticed early Monday morning, 5/29/00, the change log clearly shows that a change that affects Denver was made on Saturday night. This makes a clear starting point for troubleshooting the problem.
Strict change control policies should not be enforced only in enterprise networks. ISPs can benefit as much, if not more, from these policies. In enterprise networks, when changes are made that inadvertently affect a lot of people, business is disrupted, and there will be a lot of angry end users. A disruptive change made on an ISP network has the potential to affect many companies, causing a lot more disrupted business. Not only will there be a lot of angry people, these people have the option of switching to competing ISPs if they are not happy with the way the network operates. Strictly enforced policies minimize unscheduled disruptive changes and enable quicker recovery if problems are encountered.
Escalation Procedures
Clearly defined escalation procedures specify how long an engineer with a certain skill set works on a problem before handing the problem to a more skilled engineer. They specify who to turn the problem over to and how to turn it over. They also define how, when, and how often management is informed of issues, including how long a problem goes unresolved before it is brought to management's attention.
Updating Policies
No matter how well a policy is written, it eventually becomes outdated due to new technology or new organizations. The policies need to be updated to reflect changes. People who are responsible for implementing the policies and procedures need to be informed of and trained on the changes. Those whom the policies affect should be informed of all changes.
| 
