by John Wobus  Upgrading Your Network Backbone What do we need to know to plan the upgrade? Keep uppermost on your mind is the goal of the upgrade and the goals of the network itself. The future The fundamental information you need to plan the upgrade is the future needs of your network and your company. Of course, you may need to make assumptions about the future, and where possible, hedge your bets. Current and future capacity needs Determining future needs is not an exact science, so you'll need to build in some reserve capacity. Consider what problems can be addressed with the resources you would use to overbuild the network. Are there other areas where even more risk could be eliminated? One philosophy in planning network capacity is to design the network so that every router or switch can handle wire speed on every interface and so that every trunk can handle the maxi mum rate on each of the branches that it handles. For example, a 100-Mbps trunk would concentrate exactly 10 10-Mbps Ethernet segments. There is nothing wrong with this design philosophy if you can afford it. For workgroup situations with few users per server, it may be effective use of capital. But there are situations where such a standard would cause you to sink resources in the wrong place: if you use a single microcomputer server to launch applications for a hundred users, it would hardly be worth serving them with 10 Fast Ethernets to 10 switches each serving 10 clients on 10-Mbps Ethernet. While the network manager can rest assured that the network will slow nothing down, it is clear that the whole system would perform better with better balance between money spent on the network and money spent on the server's performance. Future applications Collect information about the applications that will be used in the future. But note that it is this information might not help you determine exact needs. The direction of network technology Unless you're omniscient, you probably won't be able to guess the future of network technology. But here, again, you can make some educated guesses. Who will design and who will implement the backbone? You may consider outsourcing some or all of the work. Many sites are geared toward outsourcing while others have the staff to do all the work. If your site is on the line between these two, naturally you will have to determine how much of the work to outsource. The process: RFP? What kind? The evaluation and purchase process depends on the type of organization you are working for as well as the portion of the design and work you intend to do in-house. You may choose to produce a Request for Proposal (RFP) to solicit potential vendors. In the RFP, outline your needs and some issues and ask the vendors to design the whole backbone. Or you can design the backbone yourself and use the RFP to ask the vendors to describe devices they can provide to fit into your design. The ATM Forum has distributed a "Mock ATM RFI" (Request for Information, at http://www.atmforum.com/atmforum/rfi/rfi_intro.html) that fits into the latter scenario: It asked for details about an ATM switch. How to incorporate such a switch in your network is up to you. If you are faced with writing an RFP, seek some examples of RFPs that have been used by your organization for other major projects or that have been used by other organizations for network upgrade projects. Follow good business writing practices: Be clear about what you expect in response from the vendor by providing a short but complete delineation of the "required responses" very near the beginning of the document. For each piece of information required, decide how important it is to you. Put less important items in a separate section further back. The vendor shouldn't decide the importance of the network elements. Disclaim any promises made by the document: Stating that your choice will be based on multiple factors along with your judgment of the vendors' ability to follow through. With an RFP you can get vendors to show what they can do for you, complete with costs, as opposed to the attractive pictures of ideal networks they will outline when left to give their canned presentations. The RFP process is far from perfect, but it can be very helpful. Can just the backbone be upgraded? A network can be designed so that the backbone can be upgraded independently from the rest of the network. If your network is not currently like this, you must stick with your vendor's upgrade path or must upgrade more than just your backbone. Some sites use a single vendor to provide all of the networking equipment for the backbone and for individual LANs. However, this equipment may be proprietary or maybe standards-based. The latter may be easier to upgrade. It is possible to use one vendors' equipment for the backbone, and another's for the rest of the network. This strategy will force you to stick to vendor-independent features when choosing networking equipment, perhaps missing out on some proprietary feature. Every vendor claiming its equipment is standards-based will be able to explain why it has chosen not to implement some prestandard feature. Also, a vendor's definition of "standard" depends its idea of a standards body. Consortiums and alliances are formed to jump-start the groundwork for traditional standards bodies (to greater and lesser degrees, the ATM Forum, the Fast Ethernet Alliance, and even the IEEE fit into this role), while new organizations may be formed to influence these, such as the Desktop ATM25 Alliance and the CIF Alliance. This gives vendors a lot of leeway in their use of the phrase "we only implement standards". Flat versus Subnetted A major issue in designing a backbone upgrade is whether the whole network is run as a single IP network-in other words, LANs are interconnected with bridges or switches- or whether the network is divided into IP subnets with a router or routers. There is constant debate about which is better. The phrase "switch when you can, route when you must" is important in the use of the words "can" and "must." Both schemes have been touted as "the scheme that scales": if you have equipment that can nicely handle 16,000 clients in a flat network, then scaling up to that is bound to be easy; on the other hand, the biggest network of all, the Internet, is far too large to be flat. In any case, your backbone upgrade is most easily accomplished if you do not change schemes. On the other hand, if you have decided to change schemes, your conversion strategy will be an integral part of your upgrade plans. Either way you move, you are likely to have to change the network configuration of every computer. You are perhaps luckiest if you have established that all your desktop machines are configured through a central bootp or Dynamic Host Configuration Protocol (DHCP) se rver. Then the work is clear and relatively centralized. If this is not the case, there are a few schemes for getting from one to the other in stages. The goal is to set up things so there is a limit to the number of computers you have to reconfigure simultaneously. Most of the schemes involve the use of a kind of transition network which allows you to "cheat" on the use of the subnet masks in the clients-use a mask that assumes a flatter network than it really is. This is done with the use of Proxy ARP, a feature of routers invented to aid in the transition from flat networks to subnetted networks. While ARP requests ordinarily request the MAC address corresponding to an IP number on the requester's subnet, a router port supporting Proxy ARP responds to ARP requests for IP numbers outside the router port's assigned subnet. In effect, the router says "use my MAC address to send to that IP address." Given that, computers on the subnet are free to act as if everything on the network is on their own subnet, which is what they would do to an extent if their own subnet mask were set "flatter" than the subnet's real mask-in other words, to imply the subnet is larger than it truly is. The transition will be helped if your address space is such that your clients are in a portion of it that can be defined by a single properly masked subnet and an equally large part of your address space is empty. The easiest transition is from a subnetted address space to a completely flat address space: After you turn on Proxy ARP on all the router interfaces, you can take your time changing the subnet mask on each computer while the network remains in production. Then you can substitute switches for routers, and you've flattened your network. Transition from highly subnetted to a partially flat address space- such as you might use to accommodate a few WAN links using subnets, to accommodate a few departments who operate independently from your central organization, or to go to a scheme using just a fe w VLANs-is more of a challenge. Here having some address space in reserve is of value. Map out your future address space, then temporarily partition it into subnets using your old mask. Next, set each of these temporary subnets as a secondary address on the LAN that has the computers that will be using the same address space. After turning on Proxy ARP, you reconfigure computers one at a time to their new addresses and masks. Then you reconfigure your routers and switches with your new address scheme all at once without worrying about any computer. To go from flat to subnetted, if you have the address space in reserve as described above, you can turn on Proxy ARP, set up your subnets so everything is in one large temporary subnet and all your future permanent subnets are in the reserved part of the address space. At this point you can move a LAN at a time, but you have to reconfigure every computer on a LAN at the time it is moved. If a LAN can be physically divided temporarily so that part of it uses the old scheme and part the new, you can reduce the amount of simultaneous work required. If you don't have such address space in reserve, or you cannot reconfigure all those computers simultaneously, you must reconfigure each computer more than once. On the first go-round, change the computer's IP addresses until they each have an address on their future subnet, but don't change the masks. Depending upon how the addresses are distributed, you may have to reconfigure some of the computers twice in this step, moving some computers to temporary addresses to free up other computers' final addresses. Once all the computers have their final addresses, move all the LANs to a router, with Proxy ARP turned on each interface. Then go through all the computers one more time, correcting their address masks. After that, disabling Proxy ARP finishes the job. Is ATM a requirement? Sometimes the industry starts assuming a particular new technology is inevitable, to the point where people start seeing its adoption as a key goal in itself. Inevitably, there will also be conservatives who will see the same technology as just one many possibilities. The result is that different organizations will have varying levels of confidence in the conventional wisdom about the future of networks. For a while, ATM filled this role: Its future seemed sufficiently secure that many sites decided that any backbone upgrade would involve ATM. Network equipment vendors sometimes asked this question to prospective customers so they would know whether it was worth pitching an alternative solution. So your site may consider ATM a requirement. If you may have such strong feelings on other technical issues, make it a point to let the vendors know up front. VLANs and ELANs VLANs promise the ability to group physically disparate users according to usage patterns and security concerns, all while avoiding moving someone's computer from one location to another. To derive these benefits, you must have compatible VLAN equipment all the way to the telephone closet-this means a single vendor for backbone and your LANs. Such a strategy might affect your backbone design decisions-and your choice in telephone closet switches. There is benefit to having your VLAN strategy set when you upgrade the backbone, but unless you are going to do significant work to the rest of your network, you are not necessarily forced to take action: Your backbone may well last a generation before the rest of your network is ready and the vendor can deliver. If you see VLANs in your future, and wish to prepare, you must choose a vendor or to commit to ATM Emulated LANs, the only non-proprietary VLANs at this point. At some point you will want to start using the VLAN-compatible (or ELAN-compatible) equipment for all expansion in the telephone closets. After there is significant deployment, the benefits of VLANs will start accrue. Moving the backbone to VLAN-compatible equipment can be done at any time during this process. How much control do you have over client administration? If your site has a lot of desktop machines that are administered by members of other departments, or are administered by users, then you must weigh the resulting coordinating efforts against the benefits of any change that creates work for these people. The other extreme is that all the clients are administered by a few people, making any necessary changes to the clients more feasible. Real-time needs One of the compelling aspects of ATM, and to some degree, the flattening of networks, is the need for quality of service, in particular for applications that use the network in real-time such as transfer of audio and video over the network as it is being displayed/played. Network-imposed security needs The backbone can be used to impose some security constraints on the network, through the use of packet filtering or proxy-style firewall protection between your individual LANs. This suggests the use of a nonflat network, but even if you are using routers, you must keep cognizant of the fact that you can build a backbone capable of high-speed transmission, then find yourself slowing it down when you implement such security features. One case is the router or switch that provides less throughput when its security features are enabled; another is to find that your firewall prevents the use of your new router's touted capacity. The first case can affect the type and number of routers or switches you need to deploy, the second case may suggest some planning to balance resources spent on router speed versus those spent on firewall speed. Reliability Requirements and Acceptable Risk An important factor is the level of reliability that your site expects, and the risk it is willing to accept that an outage will occur. It is natural to pay extra for extra reliability, but there will always be a limit to how much of your budget you can allocate towards eliminating the last bit of risk or d owntime. You know what your own site expects, but you may not be aware how your site compares with other sites in this area. The products and network designs that are pitched to you may be assuming a different level from what you expect, and other sites you talk to may also have different assumptions. To centralize or not to centralize One of the major issues in the backbone design is whether the backbone is centralized or collapsed. We will outline this issue below. Next Upgrading Your Network Backbone Is It Time To Upgrade? What Sort Of Upgrade? Evaluating Proposals Additional Issues Updated March 14, 1997 Print This Page E-mail this URL