32	ROUTER AND NETWORK MANAGEMENT

to either fix existing problems or to enable new services or functionality on your network. It is also important to decide whether it is worth upgrading all devices in the network, all devices performing one function in the network or just a single device. Upgrading all devices or all devices performing a particular function in a network will generally involve a significant effort and will carry a significant risk. However, upgrading a single device leaves a network with a variety of software versions. This makes network maintenance, support and troubleshooting more complex.

Before new versions of code are installed on a production network, it is highly advisable to test code in a lab. Clearly, if the code is urgently required to fix an outstanding problem, there will not be an opportunity to pre-test the code. In these circumstances, it is often best to implement a limited deployment in order to limit the risk associated with the deployment of new code.

3.8.1 SOFTWARE RELEASE CYCLES

Every vendor has its own release cycle. Generally, there are several phases in the software lifetime and these can be broadly described as follows:

•Pre-release. During this stage, new versions of code are tested, initially within the vendors’ own labs (commonly known as alpha) and then within selected customers’ labs (commonly known as beta). This code can never be considered bug-free. In general, beta code is somewhat more stable than alpha code. While it is almost never advisable to use alpha code on operators’ public networks and beta code is rarely recommended for general use on operators’ public networks, there are often occasions where vendors may suggest the use of beta code in isolated cases to solve particular problems or provide particular, urgently needed functionality.

•Early availability. Some vendors release code for ‘early adopters’. These are users at the forefront of technology with the most advanced requirements. They are usually more willing to tolerate the risk of slightly buggy code in order to get access to the latest features for their network.

•General availability (GA). This is the point at which code is generally considered stable enough for deployment on all networks. The features supported in this code have been deployed widely among early adopters and have been shown to be relatively stable and free of bugs.

•End of life. This is the stage in the software life cycle where vendors cease to make the software available to new customers and cease to provide bug fixes for the affected versions. Bugs found in these versions are generally checked and, if present, fixed in subsequent GA releases.

3.9 CAPACITY PLANNING TECHNIQUES

Capacity planning is a widely underrated task by service providers. It is, however, vital to be aware of where your network is reaching capacity and where you need to acquire extra

3.9 CAPACITY PLANNING TECHNIQUES

33

capacity. With provisioning cycles for high capacity links measured in months rather than weeks, it is essential that you understand the traffic trends so that you can place orders for capacity required in several months time.

There are many methods associated with capacity planning. Below are listed some of the more popular capacity planning tools:

•General traffic graphing tools (e.g. MRTG, RRD). There are numerous free and shareware applications that provide graphical and tabular analysis of interface throughput statistics. These generally pull statistics from the network device using SNMP, record them in some kind of database and then post-process the results to produce graphical or tabular information regarding the traffic through particular interfaces.

•Traffic engineering and planning tools. In addition to the free and shareware applications, which generally provide simple statistics on throughput on an interface, there are numerous commercial applications that provide a much wider functionality. They include applications that take the aggregation of the kind of information used by the ‘graphing tools’ across an entire network and plot the volumes of traffic flowing on links over time. Often this is used to produce a map of the network with colours used to display the relative ‘heat’ of a link. Hot links are then flagged for upgrade. The information over time can build up a picture of cyclic traffic flows, which are not visible from the viewpoint of a single interface on a single router. The obvious downside of these systems is that they require the pooling of vast amounts of data to provide any useful results over any period of time.

•Traps. It is also possible to use SNMP to send traps when thresholds are broken. This enables alarms to be sent on each event or for a trend to be identified if a particular threshold is regularly broken, for example, at a particular time of day or on a particular day of the week.