Cisco Knowledge Suite Cisco SystemsCisco Press

Cutting Edge
Core Reference
Guided Learning
Networking Architecture
Internet Protocols (IP)
Network Protocols
Transport and Application Protocols
Desktop Protocols
Security and Troubleshooting
Network Resources and Management
Integrated Services

Building Internetworks


< Back Contents Next >

Building Internetworks



A Blueprint for Success



Topologies for Simple Internetworks



Topologies for Large Internetworks



Before You Build the WAN



After You Build the WAN




Save to MyCKS

IP Routing Fundamentals

From: IP Routing Fundamentals
Author: Mark Sportack
Publisher: Cisco Press (53)
More Information

13. Building Internetworks

Up to this point, this book has examined many of the underlying technologies in an internetwork. These have included routers, routing protocols, and local- and wide-area networking facilities. In this chapter, you will learn how to integrate these components into an internetwork. Internetworks can consist of LANs within a single location, or networks that are scattered across the world in a wide-area network (WAN). Of these two extremes, wide-area internetworking is the more complex. Therefore, this chapter focuses exclusively on internetworking via a WAN.

A Blueprint for Success

The blueprint for success begins with gathering your users' requirements. These become the inputs that affect every facet of your internetwork, from the size and type of transmission technologies, to the placement of routers, to the choice of routing protocol. Planning a WAN requires the successful integration of all these technical components.

Successful integration means that the performance of the finished network meets, or exceeds, performance requirements and user expectations. Therefore, it is important that you identify and quantify (to the extent that users will cooperate) these performance criteria before you begin the design. After you have identified your users' performance expectations, you can begin planning for your WAN based on several factors:

  • Scale

  • Distances between user locations

  • Traffic volumes

  • Performance delays

  • Costs of the completed WAN


The first step in planning a WAN is determining its scale. In other words, how big will it be? Although this may seem to be simple, the word big can have more than one meaning. In the case of a WAN, scale refers to the number of locations that need to be interconnected. The greater the number of locations, the larger the scale of your WAN. Large-scale WANs can impose interesting challenges for the planner. Scale may prevent you from using certain topologies, transmission technologies, and even routing protocols! Therefore, it is imperative that you understand how large your WAN will be before you start to plan it.


The next factor to evaluate is the distance between the locations that you are trying to internetwork. Many of the transmission facilities available today are priced according to distance. This is particularly true with leased private lines. If your locations are thousands of miles apart, you might find that the cost of installing a dedicated private line between them is cost prohibitive. Fortunately, alternatives exist. Many transmission technologies are priced according to usage rather than mileage. Examples of these technologies include Frame Relay, X.25, and ATM.


Another way to minimize the cost of transmission facilities is through careful planning of the WAN's topology. The shape of the WAN can be manipulated to accommodate the geographic distances separating the locations that are to be internetworked. Some examples of internetworking topologies are presented later in this chapter, in the sections titled “Topologies for Simple Internetworks” and “Topologies for Large Internetworks.”

Traffic Volumes

One of the most important factors to consider when designing an internetwork is the traffic volumes that it will have to support. Unfortunately, estimating traffic volumes is an imprecise science. This is particularly true if there is no preexisting network or communications infrastructure. If such an infrastructure existed, it would provide some much-needed clues as to the overall amount of traffic that the new internetwork would have to support.

Absent such a source of information, your next best bet might be to interview users to determine the type of work they do, the locations they need access to, the estimated frequency and duration of their communications with other locations, and an estimate of the bandwidth that will be consumed by each communications session.

When collecting your users' usage volumes, keep in mind that there are actually two traffic volume metrics: maximum traffic volumes and average traffic volumes.

Maximum Traffic Volumes

In reality, actual traffic volume is almost always volatile; it varies with times of day, days of the week, business cycles, seasons, and so on. In other words, you can count on traffic volumes being anything but constant. Given this volatility, it is important to estimate the maximum amount of traffic that could be generated at any given point in time. The maximum traffic volume that you expect the network to support is known as the peak volume. As its name implies, this is the greatest amount of traffic that you expect the network to have to support.

If you design a WAN without considering peak traffic levels, it is quite likely that your users will experience a degradation of performance, if not an outright service outage, during those times of peak activity.

Average Traffic Volumes

Average volumes are the traffic loads that you can reasonably expect during the course of a business day from any given work location. This type of load is also sometimes referred to as sustained volumes.

Establishing these two traffic volumes is critical to the sizing of the WAN's transmission facilities, as well as its routers. If you expect any given location to generate an average traffic load of 100 kbps during the course of a business day, for example, it is clear that a 56 kbps transmission facility will be inadequate.

Performance Delays

Delay is one of the more common metrics that can be used to measure network performance. Delay is the time that elapses between two events. In data communications, these two events are typically the transmission and reception of data. Therefore, delay is the total amount of time that is required by the network to transport a packet from its point of origin to its destination. Given this definition, delay is an aggregate phenomenon with many potential causes. Three of the most common kinds of performance delay are

  • Propagation delaysPropagation delays are the cumulative amount of time required to transmit, or propagate, the data across each transmission facility in the network path that it must take. The size and quantity of each transmission facility in the network path directly contribute to the aggregate propagation delay of any given transmission. An additional contributor to propagation delay is traffic volumes. The more traffic that is flowing across a given facility, the less bandwidth is available for new transmissions.

  • Satellite uplink/downlink delays—Some transmission facilities are satellite based. These require the signal to be transmitted up to the satellite and transmitted back down from the satellite. Due to the potentially great distances between the terrestrial transmission facilities and the satellite, these delays can be quite noticeable. Uplink/downlink delays are actually a specific form of propagation delay. For planning purposes, you can safely estimate the round-trip uplink/downlink delay time to be approximately half a second. Due to the lengthiness of this type of delay, however, it is always described separately from terrestrial delays.

  • Forwarding delays—Forwarding delays in a network are the cumulative amount of time that each physical device needs to receive, buffer, process, and forward data. The difference between forwarding delays and propagation delays is that forwarding delay is measured per device. Propagation delay is measured over the entire network. Forwarding delay is also known as latency.

Ideally, you would interview your user community to determine their precise performance requirements, and then select networking technologies and a topology. Practically, this will never happen. Users tend not to know what they need. Their ability to assess a network's performance is usually limited to a reactive, and subjective, opinion. However, users are quite adept at identifying overall levels of performance that are unacceptable! Acceptable levels of performance tend to be a function of habit: Normal network performance is usually defined as whatever they are used to. Obviously, this is a highly subjective way to assess a network's performance. You may find this description of a network's possible sources of delays of little help in designing a WAN. An understanding of them may prove invaluable, however, when trying to figure out why your users aren't thrilled with the performance of an existing network.

Costs of the WAN

Designing a WAN ultimately boils down to a balancing act: The desired performance of the WAN must be reconciled with the cost of providing that performance level. WAN costs include the initial startup costs as well as the monthly recurring expenses. Not surprisingly, the larger and more powerful network components are much more expensive than smaller, less robust components. The greatest source of expense, however, will be the monthly recurring charges you incur for the transmission facilities in your network.

Achieving the balance between performance and cost can be painful. No one wants to design a WAN that will disappoint the users with its performance, but no one wants to design a WAN that blows the budget either! Fortunately, several guidelines can help ensure the design of a WAN that satisfies existing requirements, provides flexibility for future growth, and doesn't exceed the budget.

The capital investments in routers and other network hardware become a fixed part of the network. After they are placed in operation, they must be depreciated over three to five years. You might find yourself stuck with purchased hardware for years after your network outgrows it! Therefore, it might make more sense to buy a larger router, and then add its internal components as you need them. This allows future expansion at modest incremental costs, and little (if any) operational downtime.

Transmission facilities, in comparison to most pieces of internetworking hardware, are relatively easy to replace with other transmission facilities. In theory, they can be replaced as often as your lease agreement with the carrier permits. In practice, swapping out the transmission facilities in your internetwork can be quite disruptive to operations. At a minimum, you will need to carefully plan and coordinate every aspect of such an upgrade. As with physical hardware, your best approach may be overengineering your transmission facilities relative to projected bandwidth requirements.

Applying the wisdom behind these guidelines can help you meet your users' present and future expected requirements within the constraints of your budget. The next step in the planning of your internetwork is the selection of a topology. Topologies can be highly varied. More importantly, they can be customized to fit your particular needs. Therefore, consider the sample topologies presented in the next two sections as information, rather than an actual plan, when building your internetwork.


< Back Contents Next >

Save to MyCKS


Breaking News

One of the primary architects of OpenCable, Michael Adams, explains the key concepts of this initiative in his book OpenCable Architecture.

Expert Advice

Ralph Droms, Ph.D., author of The DHCP Handbook and chair of the IETF Dynamic Host Configuration Working Group, guides you to his top picks for reliable DHCP-related information.

Just Published

Residential Broadband, Second Edition
by George Abe

Introduces the topics surrounding high-speed networks to the home. It is written for anyone seeking a broad-based familiarity with the issues of residential broadband (RBB) including product developers, engineers, network designers, business people, professionals in legal and regulatory positions, and industry analysts.


From the Brains at InformIT


Contact Us


Copyright, Terms & Conditions


Privacy Policy


© Copyright 2000 InformIT. All rights reserved.