NET 226 - Designing Internetwork Solutions
Chapter 5, Designing a Network Topology, part 1
Objectives:
This lesson discusses designing a network from the
perspective of its components and connections. Objectives important to
this lesson:
- Hierarchical design
- Flat design vs. hierarchical design
- Mesh vs. hierarchical-mesh
- Redundant design
- Modular design
- Campus network and spanning tree
- Virtual LANs
Concepts:
Chapter 5
Introduction
The chapter presents a discussion of four major concepts that
relate to topology. The text
defines a topology as a map of
a network that shows its segments, its interconnection points, and its
user communities. This kind of map was discussed in the last chapter as a tool for understanding a network. This chapter looks at a topology as
a tool for planning and designing a network. A Cisco
Learning article concerning this topic can be reached with this link.
The text makes a point on page 121 that a network that grows without
a plan presents problems to its administrators and users. The author calls
this a fur-ball network, but she does not explain the metaphor. It may
be best if we don't dwell on it.
Hierarchical design
The
first of topology topic discussed is hierarchical
network design. The illustration on page 120 defines this
topology as having three parts:
- core layer -
routers and switches optimized to carry lots
of data and to have high availability, it acts as the backbone of the
network, and carries data between sites
- distribution layer
- routers and switches with lower
capacity than those in the core layer that implement policies, and
that connect as a between the access layer and the core layer; they
translate protocols as needed between the other two layers
- access layer - the
layer of switches and wireless access
points through which users connect their stations to the network, as
well as the edge routers that
connect LANs to the distribution layer
Back to page 121, the author explains that an unplanned
network may grow by adding more and more switches, which can produce a
network with only one broadcast domain. This means that any broadcast not only reaches every host on the network,
it interrupts each host's
processor, wasting time on a message that does not concern most of
them. A hierarchical design avoids this problem by producing subnets
that are separate broadcast domains. Each subnet is a separate module in the network, and more may
be added without causing needless traffic through existing subnets.
This design also minimizes traffic from one router to another, avoiding
the traffic that would be caused by all routers talking to each other
constantly.
Flat design vs. hierarchical design
While hierarchical design includes a modularity that allows
for easy expansion, the author tells us that a network that is small and that is meant to remain small may be fine with a flat design. The main drawback the
author points out on page 122 is that troubleshooting may require
looking at the entire network. In a flat design, all hosts readily
interact with every other host.
In the illustrations on page 123, the text shows us two WAN topologies. In the first,
routers at four locations are linked in a flat ring. Each router connects to
two others, providing a choice of two routes to any of the other
routers. A route to another router may be one, two, or three hops.
Adding more routers to the ring will increase the number of hops to
reach other routers in this flat example.
In the second illustration, we see six routers, two of which are in
Medford. They are elevated to an upper
layer. They serve as gateways to other networks. Each of the remaining
four routers are on a lower layer. They are directly connected to each
of the two gateways in Medford, which places the lower level routers
one hop away from each Medford router. To reach another bottom layer
network, a router only has to contact a Medford router (one hop), then
connect to the desired router, a total of two hops. Every route in this
design will be one or two hops, which is more efficient than three. The
number of hops to another network will not
change if we add more networks in either layer.
 The author
continues her discussion of flat networks, explaining that hubs were used in flat networks
in the early and mid 1990s, but they became troublesome as networks
grew. Every device plugged into a hub is in contention with every other device
for network access. Bridging from one hub to another just makes the
problem worse. The problem was reduced when OSI Layer 2 switches were
introduced, which notice the MAC address of each attached device, pass
traffic to the necessary port, and do not
pass traffic to unnecessary ports. All devices attached to connected
switches are still on one broadcast domain, but adding a layer of routers reduces broadcast traffic,
because routers typically do not forward broadcasts from one network to
another. The hierarchical design of a subnet for each switch or for
groups of switches, reduces the problem.
Mesh vs. hierarchical-mesh
The illustrations on the bottom of page 124 each show five
routers. In the first illustration, the routers are connected in a ring
(a pentagon, actually), each connecting to two other routers. Three of those
routers are also connected to a third
router. This provides multiple routes for some of the routers to select, which
makes this a partial mesh. In
the second illustration, every router in the pentagonal ring is
directly connected to every
other router, which makes this a full
mesh. The redundancy of these connections makes the network more
resilient and reliable, but there is a cost. The formula at the top of
page 125 tells us that for a network of n routers, we
would need to make
(n * (n - 1))/ 2
connections for a full mesh of those devices. This runs into a lot of
cable and a lot of NICs. The text proposes that a better design is the
compromise of adding some redundancy to the connections in a hierarchy,
as shown on the top of page 126. It is the same design we saw on page
123, but it has been expanded to include a new layer. Each router in
the
bottom layer is still connected to two other routers, but the routers
in the uppermost layer are connected to three routers, and each router
in the middle layer is connected to four or more routers. This design
give a lot of redundancy but less than full redundancy.
Page 126 also shows an illustration of a more common hub and spoke hierarchy. Think of
the central office of this company as the center (hub) of a wheel, and
each
satellite office as the end of a spoke of that wheel. This common
design does not use any redundancy, so each connection is an important
one to someone. Note: the use of
the word hub in this case has nothing to do with the concept of
network
hubs. It's nice to use the same word for two things, isn't it?
This takes us to an expanded discussion of the hierarchical
model. Some of the information here is summarized in the bullet list
above. The author also shows us two common mistakes made in
hierarchical networks on page 129. In the first example, on the left side of the illustration, an
admin has connected a new router to another router on the access layer.
This creates a chain, a new
layer in the network. That new router should have been connected to a
router on the distribution layer, to maintain what the author calls the
network diameter. In the
second example, on the right side of the illustration, we see a new
router has been connected to two routers on the access layer. The
author calls this a back door
error. It leads to additional routes that the routers must communicate
to each other, and to a loop in that part of the network. Again, this
new router should have been properly connected to a router in the
distribution layer to make it a proper member of the network. These
errors could be made by connecting a router, a switch, or a hub
incorrectly.
Redundant design
As we have already seen in the mesh examples, redundancy on a
network can provide reliable
connections when one component goes down. The author explains that we
should consider redundancy for any
critical network component, not just linkages through routers. Well
engineered redundancy increases reliability, but it increases expense
as well, so the text cautions us to consider the client's budget when
planning redundancy.
Redundant routes are discussed on page 131 under the topic of backup paths. (This is about having
a second or third choice of a route, not about backup of data.) When
routers select routes, they typically select the best on based on some
metric, so you can optimize your network performance by supplying
metric data that your routers understand. This can lead to the author's
desired state of automatic failover,
which is preferred over a manual process to change available routes.
The author also discusses load
sharing, which is sometimes called load balancing. With regard to
networking, you need to know that load sharing splits a data stream
across multiple routes, and reassembles them on the far end. We expect
this to happen for every packet in an IP network, so this should not be
a new concept.
Modular design
The author suggests that we can also consider creating a
network as a set of modules that are meant to interact in proven ways.
She recommends a structure that Cisco calls SAFE. Its twelve major
components are described on pages 134 and 135. The remainder of the
chapter discusses several of these modules.
Campus network
The major topic under the author's discussion of our campus
(main) network is spanning tree
protocol. This protocol was developed to deal with a problem
that arises in networks that have redundant paths to a given
destination. Weren't we told we should have redundant paths? Yes, we
were, and yes, we should. So, what's the problem, since the author
doesn't seem to want to describe it? Well, she does tells us that the
rules for this kind of situation were invented when everyone used
bridges to connect or divide network segments, so she is using the word
"bridge" to mean both bridges and layer 2 switches. That's good to
know. Now, the problem:
The bottom line is that bridges
and switches are (mostly)
layer 2 devices. They work with MAC addresses. When there are two (or
more) paths across switches from one segment
to another, and the switches
on those paths both forward
packets, each switch sees the packet forwarded by the other switch, and
the devices get confused about which segment the addresses live on.
This is bad.
Enter the spanning tree protocol, like a hero to solve our
problem. The protocol says that if there are two ways to cross over to
another segment, the devices will determine which device has the best connection, and use the route
across that device. The
process of choosing the best path involves each device sending
information about itself and its connections to every other such
device. This process is carried out every time a new path is added or
lost, and the process of defining the preferred paths is called convergence. The text tells us that
Rapid Spanning Tree Protocol (RSTP) allows devices can reach
convergence in "a few hundred milliseconds". (page 137)
Every port on a switch can be in one of several states. Three
are listed on page 137:
- Discarding - a port in this state does not learn new MAC addresses or forward frames
- Learning - a port
in this state is learning MAC addresses and associated ports, and is
writing information in the MAC address table of its switch/bridge
- Forwarding - a port
in this state is doing the things in the learning mode, and it is also
forwarding frames based on information in the MAC address table
Spanning tree protocol also causes bridges to elect a root
bridge. Remember that information the bridges/switches send about
themselves? It includes their IDs, composed of their MAC address and a
code assigned by an admin. The bridge with the lowest ID is
automatically the root bridge. Note that the admin can rig the election
by assigning a low code to a favorite bridge. If all codes were the
same, the bridge with the lowest MAC address would be the root bridge.
Another feature of the spanning tree protocol is
that it calls for each device to participate in sharing its information
regularly. If a designated bridge (the one being used for a segment)
has failed to communicate recently, the root bridge can call for a new
election, which will result in choosing a new designated bridge for a
segment whose designated bridge has gone down.
Virtual LANs
This section of the chapter contains an unrelated nugget of information. The author defines a bandwidth domain
as any set of devices that share bandwidth or compete for access to it.
In a classic wired Ethernet, there was one bandwidth domain, because
all devices on that LAN competed for access with each other. In an
Ethernet with switches, the text tells us that each device that is
wired to a switch is on its own bandwidth domain, but this is a little
specious, since the there is no point in communicating only with the
switch.
The text also defines a broadcast domain
as the set of devices that can receive each other's broadcasts frames.
This is better definition than we usually see. We are reminded (or
told, if we did not know) that the broadcast address for layer 2 is a
MAC address that is all Fs.
The text turns a corner and steers toward VLANs.
Users anywhere on your network can be made members of a common Virtual
LAN, which lets them communicate as easily as if they were on the same
LAN. This was the original use of VLANs. They are not often used for this purpose any longer. Usually, VLANs are used, as the text says, to make a large switch act as though it was really several
switches, so that it can be used to separate groups of ports into
different VLANs. This has the benefit of having each VLAN act as a
separate broadcast domain, minimizing broadcast intrusions for all
devices plugged into ports on that switch. A virtual router on the
switch connects the separate VLANs the same way a real router would.
As you might imagine from the description of VLAN users being
anywhere in your network, a VLAN can exist on specific ports of
multiple switches. When this is done, the connections between the
switches that contain the parts of a VLAN are called trunks or trunk links.
Frames traveling from one such switch to another are given a header
identifying the VLAN it belongs to. The header is called a VLAN tag.
|
