Cisco Network Topology and Design
This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter explores design issues related to overall network topology. The following sections discuss the traditional issues of bandwidth, delay, and reliability; as well as the often overlooked issues of operational simplicity and scalability, particularly as they pertain to routing. Specifically, the following issues are discussed:
Requirements and constraints of the network—This section examines the requirements of a network and the importance of scalability and extensibility. You will also read about constraints on the design effort, including labor, economic, social, time, and space issues; as well as the need to support legacy technologies.
Tools and techniques—You will explore some of the tools for building large networks. Modularization, layering, multiplexing, and caching are discussed in the context of the overall design. This section briefly examines the use of soft-state mechanisms, hysterisis, and dampening in routing protocols; and finally discusses network failure modes.
Issues of hierarchy—This section demonstrates that hierarchy and redundancy must be carefully balanced to craft a network that can grow to meet future needs without becoming an operational nightmare. Experience gained from the Internet is also discussed. (For additional information on this topic, see Chapter 1, "Evolution of Data Networks.") Finally, this section examines the principles of layering and regionalization of a large network into core, distribution, and access networks.
Backbone network design, as well as distribution, regional network design, and access design—In these three sections, you will examine the details of designing core, distribution, and access networks. The role of each is discussed, and the pros and cons of various approaches are described.
Requirements and Constraints
Before delving into the typical topologies, it is wise to understand the overall network design process. As with any systems design effort, network design is an exercise in meeting new and old requirements while working within certain constraints. These constraints include money, labor, technology, space, and time. In addition, there may be social or political constraints, such as the mandated use of certain standards or vendors.
Economic constraints play a major role in any network design. Unless you are very fortunate, you often must compromise in the capacity of WAN links, the switching capabilities of routers, the type of interfaces used, and the level of redundancy achieved. Achieving the "best possible service at the lowest possible cost" was a design paradigm invented—tongue-in-cheek, to some extent—by one network manager to satisfy both management and network users. This paradigm fails to explain how this task is achieved, other than through a carefully considered compromise, but neither does it say anything that is incorrect.
Labor effort should be of paramount concern in any network design. In this case, the first area of concern is the amount of effort and level of skill necessary to connect a new customer to the network or to expand the capacity of the network infrastructure. As a general rule, the more often a task must be executed, the more the design should focus on making that task simple and efficient—in other words, the goal involves optimizing the common case. In addition to prudent network design, labor costs can also be reduced through investment in network management tools. It is noteworthy that for many networks, the capital cost is dwarfed by the ongoing charges for highly skilled support personnel.
Processor speed doubles every 18 months. Nevertheless, as you have already seen in Chapter 1, Internet traffic levels can increase at a far more rapid rate. Thus, computation is still a constraint of network design, particularly in the case of routers. Typical computational limitations that apply to network design are associated with processing of routing updates, accounting, security filtering and encryption, address translation, and even packet forwarding.
Space issues include the physically obvious, such as the cost of expensive air-conditioned points of presence (POPs) or co-location facilities. Space also includes subtler, but nonetheless important resources, such as the buffer capacity in a router or the bandwidth of a WAN link.
One time constraint that affects the success of a design is the time-to-market. It is useless to design an extremely sophisticated network if the customers have gone elsewhere by the time it is operational. Time constraints also include packet forwarding and propagation delays, which have a fundamental impact on bandwidth (in a TCP/IP environment) and response time.
Social constraints include those that may not seem sensible to achieve the major requirements of the network. These could include a mandated use of standards that are difficult to obtain, to use, or to understand. Thankfully, this has been less common since the demise of OSI. (At one time in the industry, a play on the OSI reference model included a "political" layer above the application layer—the so-called "eighth layer of networking.") Alternatively, you may be constrained to using a certain vendor's equipment because of a prearranged partnership agreement.
The need to support legacy applications is usually expressed as a requirement, but it generally manifests itself as a serious constraint. Building networks that are backward-compatible with legacy applications—such as the need to support protocols such as SNA and DECNET—can be extremely demanding.
Scalability and extensibility are the hallmarks of a good network design. They will haunt or compliment you long after the economic pain is forgotten. This is why network routing is so critical to the design process. Switching and physical-layer technologies may come and go, but the network control plane (of which routing is a major part) must survive many generations of underlying technology.
The control plane is much more difficult to upgrade incrementally than the technologies of the underlying layers, so careful planning pays dividends. In the networking world, those dividends can return in months rather than years.
Many writings on network design emphasize the importance of requirement analysis. Indeed, in terms of the initial delivery of a turnkey, or productized network service, requirement analysis is very important. However, in our experience, nowhere in the industry does the initial-requirements definition document age more quickly than in large-scale networking—particularly where the Internet is involved.
Too many network designs never leave the ground because of an overly zealous requirements-definition phase. This is an unfortunate side effect of vendors providing "shrink-wrapped" networks to customers.
Valuable engineering cycles spent on extremely detailed requirements or network flow analysis would be better spent ensuring an extensible and scalable network infrastructure, and explaining contingency plans to the customer, if the actual requirements exceed those projected. Unfortunately, stringent requirement analysis seems to be a contractual necessity, so this situation is unlikely to change.