by John Wobus  Upgrading Your Network Backbone Additional Issues Justification You may have to sell the idea of an upgrade to your peers and superiors, and even after it is sold, you may be asked to provide a justification. Ideally, you can point to a problem, state how the upgrade will address it, then be able to prove after the fact that it did. Things are seldom that easy. There is no doubt that it will help if you have documentation about how the existing network has performed over the last few years. For example, having statistics showing an increase in use of the backbone. You will often find that people are most interested in assuring to themselves that the network will handle some new applications that are being deployed. You may well discover the best support for the upgrade comes from people responsible for new applications who sincerely but wrongly believe their applications will require sign ificantly more bandwidth. The backbone is in the category of infrastructure: a central service which is supposed to help the efficiency of the organization by pooling all the cross-departmental and interbuilding communications needs of the organization. The alternative to a backbone is a hodgepodge of links between departments that need to intercommunicate. You will have more help from departments justifying their own needs than the composite needs of the entire organization. The very decision to make use of a backbone is based partly on faith: By providing service in a general way, everyone will benefit. The very same principles apply to the backbone's upgrade. It is often a challenge to produce a clear justification. Sparing and maintenance costs A major issue is how much to spare, and how much to depend upon maintenance contracts. Typically, these days, on-site maintenance for networking equipment is relatively expensive and many sites prefer to swap parts themselves. If you choose that route, you may find that your vendor offers a plan where they will ship replacement parts overnight. If you cannot stand an outage that long, you need a more expensive plan, or need to maintain spares. When maintaining spares, a network built out of smaller identical elements has a natural advantage of a network with one large element (a single router or switch) because each spare you buy may serve as replacement for more than one part. Network Management Network management is an issue not to be forgotten. In a flat network, it is especially vital to have the ability to track down computers on the network that are causing problems quickly, so a hub management system that allows you to search out MAC addresses, and an up-to-date administration database that relates ports to people who can fix the computers are important. You will be forced to turn off ports first and ask questions later, and will have to be able to handle the telephone calls you will get when you do that. Large scale enterprise managers such as HP OpenView, SunNet Manager, IBM NetView, and Cabletron Spectrum make it a point to track the routers on the network and extract their MIB II information. Such would be a large advantage in a network with more than a few routers. On the other hand, for any network device that you have a lot of, you want the best management its vendor provides even if it is through the vendor's proprietary management platform. This is true of switches, routers, and hubs, and in the case of VLANs, it is possible that you will have no other choice. If your staff is trained on the ASCII telnet or serial line-mode management features of your equipment, it is quite possible that they will use that more than any graphical management system. And if the graphical management system is immature, the reliability of the line-mode management features will be very welcome. Another specialized product is the system that monitors statistics, often through the use of RMON probes or proprietary probes typically with features beyond RMON. You will probably find the features of such a system much stronger than the equivalent portion of one of the enterprise management systems. Troubleshooting There are two troubleshooting issues with the backbone: how you troubleshoot the backbone and in what way the backbone helps or hinders your troubleshooting of the LANs that it is interconnecting. For a backbone in a large LAN, you pretty much need vendor support: Thus it is worth your while to find out about the quality of support provided by the vendor and take it into account in your purchase decisions. Hot swappability of the parts within your backbone devices is of value to troubleshooting: You avoid situations where you must choose between bringing a lot of the backbone down versus dealing the addressing of a particular problem until a better time for a large-scale outage. One troubleshooting issue which often goes hand and hand with a backbone upgrade is handling ne wer, higher speed technologies. You may have an investment in 10-Mbps Ethernet analyzers, and find yourself moving into 100-Mbps Ethernet, FDDI or ATM, for the backbone itself or for newly upgraded links to the outlying LANs. Ideally, you would acquire analyzers for any new LAN technologies being incorporated, but you will have to weigh that against the cost and possible immaturity of the tools available. You are likely to be using more switching as your LAN is upgraded over time: if not in the backbone, then still very likely in the LANs that it is serving. Where it used to be easy to put an analyzer or probe and see a whole LAN, now you have a switch working against you. You will want to consider switch features that can be used to overcome this: built-in RMON, and troubleshooting ports that can be directed to tap into the traffic passing through any other port. End Upgrading Your Network Backbone Is It Time To Upgrade? What Do You Need To Know? What Sort Of Upgrade? Evaluating Proposals Updated March 14, 1997 Print This Page E-mail this URL