Hierarchical Topologies

Most of us learned hierarchy early in life. Anyone with older siblings learned what it was like to be at the bottom of a hierarchy! Regardless of where you were first exposed to hierarchy, most of us experience it in many aspects of our lives. Hierarchy helps you to understand where things belong, how things fit together, and what functions go where. It brings order and understandability to otherwise complex models. If you want a pay raise, hierarchy dictates that you ask your boss, not your subordinate. That is the person whose role it is to grant (or deny) your request.

Hierarchy has many of the same benefits in network design that it does in other areas. When used properly in network design, it makes networks more predictable. It helps you to define and expect at which levels of hierarchy you should perform certain functions. You would ask your boss for a raise because of his position in the business hierarchy; you would not ask your subordinate. Likewise, you use tools like access lists at certain levels in hierarchical networks and avoid them at other levels. Let’s face it, large networks can be extremely complicated, with multiple protocols, detailed configurations, diverse technologies, etc. Hierarchy helps you to summarize a complex collection of details into an understandable model. Then, as specific configurations are needed, the model dictates the appropriate manner in which those configurations should be applied.

Benefits of Hierarchical Topologies

Hierarchy can be applied to network topology in many ways, and Cisco has long encouraged using hierarchical design when designing the network topology. The benefits of hierarchy to network topology include improvements to

• Scalability

• Manageability

• Performance

• Cost

Let’s look at each of these in a bit more depth.

Scalability

Hierarchical networks are easier to scale than other models. Hierarchical networks are actually composed of many individual modules, each with a specific position within the hierarchy. Because their design is modular, expansion can often be as simple as adding new modules into the overall internetwork.

Consider the network shown in Figure 5.1. This example has one main office, two regional offices, and four sales offices. Notice that the configuration is hierarchical.

Figure 5.1: A basic hierarchical network

Now suppose that this company grows to the network shown in Figure 5.2. Here, a regional office and four sales offices have been added. Notice that the size of the network has nearly doubled without significantly changing the network topology! Since hierarchies are modular by nature, additional modules (routers) were added into the existing hierarchy in a predictable way. It is not necessary to reconfigure the entire network for every expansion, and growth can be dealt with in a controlled and efficient, rather than painful, manner.

Figure 5.2: An expanded hierarchical network

Manageability

Anyone familiar with legacy Ethernet will recognize what great fun it is to troubleshoot 10Base2. If the network is down, where do you begin (assuming you lack sophisticated diagnostic tools)? 10BaseT may have required more cable to install, but the cost was almost always justified because it is so much easier to troubleshoot a star-type network than a bus-type network. Hierarchical networks offer similar advantages in troubleshooting. It is much simpler to isolate problems within a hierarchy than in other models such as meshed networks. Consider the example in Figure 5.2. When the WAN links fail, it is easy to isolate where the break is with just a few pings. Congestion issues are also easier to isolate and remedy in hierarchical networks than with other designs.

Performance

Performance alone may well justify hierarchical network design. Networks that use hierarchical design can take advantage of advanced routing features such as route summarization. This means smaller routing tables and faster convergence in large networks. Meshed networks require larger routing tables and converge slower due to the greater number of possible paths.

Cost

In the end, overall cost is often the driving force. Due to the properties discussed in this section, hierarchical networks generally require fewer administrator hours to maintain and can make more efficient use of hardware and other resources. Hardware needs can be anticipated more readily than in non-hierarchical networks. WAN bandwidth can be more accurately purchased and shared between layers of hierarchy.

Three-Layer Hierarchical Model

Cisco defines three layers of hierarchy, each with specific functionality:

• Core

• Distribution

• Access

Each layer has specific responsibilities. Remember, however, that the three layers are logical and not necessarily physical. The concept of three layers does not have to mean three separate devices. Consider the OSI model, another logical hierarchy. The seven layers describe functions but not necessarily protocols, right? Sometimes a protocol maps to more than one layer of the OSI model, and sometimes multiple protocols communicate within a single layer. In the same way, when you build physical implementations of hierarchical networks, you may have many devices in a single layer, or you might have a single device performing functions at two layers. The definition of the layers is logical, not physical.

Before examining these layers and their functions, consider a common hierarchical design as illustrated in Figure 5.3. The phrase “keep local traffic local” has almost become a clich in the networking world. However, the underlying concept has merit. Hierarchical design lends itself perfectly to fulfilling this concept. Now, let’s take a closer look at each of the layers.

Figure 5.3: Hierarchical network design

Core Layer

The core layer is literally the core of the network. At the top of the hierarchy, it is responsible for transporting large amounts of traffic both reliably and quickly. If there is a failure in the core layer, every single user can be affected. Therefore, fault tolerance is an issue. The core is likely to see large volumes of traffic. Speed and latency are driving concerns here. Given the function of the core, you can now consider some design specifics. Let’s start with some things that you know you don’t want to do at the core:

• Don’t do anything to slow down traffic. This includes using access lists, routing VLANs, packet filtering, any type of packet manipulation, etc.

• Don’t support workgroup access.

• Avoid expanding the core when the internetwork grows (i.e., adding routers). If performance becomes an issue in the core layer, give preference to upgrades over expansion.

There are a few tasks that you want to make sure to get done as you design the core. They include

• Design the core layer for high reliability. This means redundancy and fault tolerance should both be included.

• Design with speed in mind. The core should have very little latency; it should be fast and efficient.

• Select routing protocols with lower convergence times. Fast and redundant data link connectivity is no help if your routing tables are shot!

A common question network designers face today is the question of whether to use Layer 2 (bridging) or Layer 3 (routing) in the core. Each of these solutions offers some advantages and disadvantages. Layer 2 is generally faster and more scalable but offers less control over load balancing, broadcast control, and router peering. As with many design decisions, it depends on the situation which technology is more appropriate in the core.

Distribution Layer

The distribution layer is where much of the action is. Whereas in the core the emphasis is speed, at the distribution layer the emphasis is control. This is the place to implement policies for the network. Here, you can exercise considerable flexibility in defining network operation. There are several tasks that generally should be done at the distribution layer:

• Implementing tools such as access lists, packet filtering, QoS, and queuing

• Implementing security and network policies, including address translation and firewalls

• Redistribution between routing protocols, including static routing

• Route summarization and route filtering

• Load balancing

• Routing between VLANs, and other workgroup support functions

• Providing redundant connections for access devices

Avoid implementing functions at the distribution layer that exclusively belong to one of the other layers.

Access Layer

The access layer controls user and workgroup access to internetwork resources. Some of the functions to be included at this layer are

• Continued (from the distribution layer) access control and policies

• Creation of separate collision domains (segmentation)

• Workgroup connectivity into the distribution layer

Technologies such as DDR (dial-on-demand routing) and Ethernet switching are frequently seen in the access layer. Static routing (instead of dynamic routing protocols) is seen here as well. There are some functions to avoid at the access layer. Take a look at Figure 5.4.

Figure 5.4: Access layer additions

New routers should not be added below the access layer. To do so would expand the diameter of the network, which breaks the predictability of the topology. Should you need to add new routers to support additional workgroups, they should communicate through the distribution layer and thus be peers (instead of subordinates) to the other access layer routers.

As already noted, having three separate levels does not have to imply three separate routers. There could be fewer routers, or there could be more routers. Remember, this is a layered approach. In this book’s case studies, you will consider several scenarios where the functionality of several layers is collapsed inside a single internetworking device.

The three-layer model should be adequate for most small- to medium-sized networks. Only the largest networks might require additional layers.